Re: Is it possible to share a physical interface and a routing

Hi Andrew,

Wow, snowboad!
Are you in Vancouver, perhaps? ;)
Please enjoy it and forget ccie things for a while.

Anyway, I will keep learning MPLS/VRF further.
Maybe update or another question soon.

Thanks,

Achi :)

> You are the man, good stuff indeed!!!
>
> For me, my slogan for today is
>
> "Fresh snow, on PTO, lets go!"
>
> me = snowboarding today
>
> Have a great day team!
>
> Andrew Lissitz
>
>
> .
> On Wed, Feb 3, 2010 at 9:19 AM, Atsuhiro NAKAMURA
> <a-naka_at_mtf.biglobe.ne.jp <mailto:a-naka_at_mtf.biglobe.ne.jp>> wrote:
>
> Dear Andrew,
>
> Thank you very much, your advise and the CCO document helped me and
> it's working fine now.
>
> I just put vrf static route with interface option, very simple solution.
>
> Best regards,
>
> Achi :)
>
>
> Dear Andrew,
>
> Thank you for your comments and providing your knowledge!
>
> Wow, "Route Leaking"... I didn't know that, sounds interesting.
>
> Anyway I try it today and update soon.
>
> Best regards,
>
> Achi :)
>
> I did something similar in my lab when trying to learn VRF
> Lite. I do not have the set up running anymore ... ;-(
>
> Basically you have VRFs off of a global router and you need
> to share some access to and from the VRF / global tables.
> This can be done via a manual process.
> In my lab, I used global static routes to advertise these
> VRF resources into the global table. I simply redistributed
> these static routes into my global OSPF and now every other
> global router knew of these destinations.
>
> I then used static routes within the VRF's routing table to
> advertise reachability to global resources. Again, I
> redistributed the static routes into my VRF routing process.
> Lastly when return traffic would come from global locations
> and hit my global router, I used static routes to the inside
> VRF interface. Sounded weird to me too! But it works fine
> on the router and return traffic was routed just fine.
> Everything worked and it was a bugger to get working ...
> mostly because I had to think through everything and I was
> learning the entire time. (watch the ugly word wrap):
> http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_example09186a0080231a3e.shtml
>
>
> Good luck and hit us back with any questions and or comments,
>
> Andrew Lissitz
>
>
> .
> 2010/2/1 <a-naka_at_mtf.biglobe.ne.jp
> <mailto:a-naka_at_mtf.biglobe.ne.jp>
> <mailto:a-naka_at_mtf.biglobe.ne.jp
> <mailto:a-naka_at_mtf.biglobe.ne.jp>>>
>
> Hi guys,
>
> Is it possible to share a physical interface and a
> routing by some VRFs?
>
> I need to connect one local hub CE router R1 and some
> remote spoke
> CE routers R2, R3, ..., Rx via GRE tunnel.
> I also need to isolate them by using VRF on R1, because
> remote sites
> address space can be overlapped.
>
> R1 fa0/0 -------+------- R2
> +------- R3
> +------- .
> +------- .
> +------- .
> +------- Rx
>
> To establish GRE tunnel for each remote spoke CE router,
> I want to
> share the physical interface fa0/0 and default route via the
> interface by those VRFs.
> I don't want to configure several loopback interfaces for
> every each
> site, because I have only 1 global ip address which is
> reachable
> from each remote site.
>
> I would appreciate it if anybody gave me an idea.
>
> Achi :)
>
>
> Blogs and organic groups at http://www.ccie.net
>
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
>
>
> --
> Andrew Lee Lissitz
> all.from.nj_at_gmail.com <mailto:all.from.nj_at_gmail.com>
> <mailto:all.from.nj_at_gmail.com <mailto:all.from.nj_at_gmail.com>>
>
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> Andrew Lee Lissitz
> all.from.nj_at_gmail.com <mailto:all.from.nj_at_gmail.com>

Blogs and organic groups at http://www.ccie.net
Received on Thu Feb 04 2010 - 07:38:40 ART