[c-nsp] Inter VRF Routing help needed

Thu Sep 18 19:00:27 EDT 2008

Cc loo

VRF-Lite cannot share routes internally in the router. You will need to
do BGP/VPNv4 or loop out and back in some physical interfaces on your
router and run a routing protocol between all of the VRF-lites over
those interfaces.

An RD will just define the VRF and the RD will stay the same in all your
PE routers in a BGP/VPNv4 network. The RT's are really extended BGP
communities to allow export and import of BGP/VPNv4 routes. Doing what
Andy was showing is also known as overlapping VPNs. All VRF's will have
a unique RT also but you can add other RT's to them to overlap other VRF
routes.

Bryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of cc loo
Sent: Thursday, September 11, 2008 9:50 PM
To: Andy Saykao
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Inter VRF Routing help needed

Hi,
Thanks for all the replies, i will go do more homework/reading up and
practice in my work place :D

On Fri, Sep 12, 2008 at 6:48 AM, Andy Saykao <
andy.saykao at staff.netspace.net.au> wrote:

> Hi cc loo - It took me a while to understand the difference between RD
> and RT's too.
>
> Most literature will have examples of where the RD and RT are exactly
> the same and you can't help but be confused when you see them being
> different and you'll start to ask yourself "what's the point of having
> this RT statement when it's identicle to the RD - seems like a waste
of
> time". But they do play a very important role when you start moving
away
> from simple VRF design.
>
> What's most important to remember is that the RD and RT can be the
same
> or can be totally different and that they both serve completely
> different purposes. Generally, in a very simple VRF set up (eg: one
> customer with 3 sites all being able to talk with each other and
> exchange data), the RD and RT will be the same because you probably
> won't be leaking routes between VRF's because this isn't a
requirement.
> The RD is basically a way to allow overlapping IP addresses to exist.
If
> we take the example of vrf_customer_A (RD 1:1) and vrf_customer_B (RD
> 1:2) - both can choose to use 192.168.1.0/24 and the address space
will
> be completely unique because the RD is combined with the IPv4 address
to
> produce the VPNv4 address like so - RD:192.168.1.1.
>
> The RT on the other hand is a BGP extended-community attribute that is
> also tagged onto the VPNv4 address to allow you to be able to
> import/export these routes to other VRF's.
>
> ip vrf customer_A
>  rd 1:1
>  route-target export 1:100
>  route-target import 1:900
> !
> ip vrf customer_B
>  rd 1:2
>  route-target export 1:200
>  route-target import 1:900
> !
> ip vrf Hub
>  rd 1:9
>  route-target export 1:900
>  route-target import 1:100
>  route-target import 1:200
>
> So in Oli's example, a host of vrf_customer_A might have a VPNv4
> addresses of 1:1:192.168.1.1 and RT 1:100. Likewise a host of
> vrf_customer_B might have the VPNv4 address of 1:2:192.168.2.1 and RT
> 1:200. The routes with the corresponding RT's of 1:100
(vrf_customer_A)
> and 1:200 (vrf_customer_B) are imported by the Hub and so the Hub will
> end up with the routes of 192.168.1.1 and 192.168.2.1 in it's own
> routing table and will be able to reach these two hosts eventhough
they
> are in different VRF's. Similarly, vrf_customer_A and vrf_customer_B
> need to import the RT that the Hub is exporting (1:900) so they too
can
> reach the Hub.
>
> I've deliberately used different IP space for customer_A and
customer_B.
> Just be careful if you plan to import/export route's between different
> VRF's because you'll need to make sure the routes are unique in this
> case. Imagine if customer_A and customer_B were both using
> 192.168.1.0/24. How would the Hub be able to distinguish if it should
be
> sending to customer_A or customer_B - hence why you need to do some
> planning so as not to run into this problem.
>
> Sorry if it was a bit long winded. I'm new to all this too ;)
>
> Cheers.
>
> Andy
>
> cc loo <mailto:s00664233 at gmail.com> wrote on Thursday, September 11,
> 2008 5:05 PM:
>
> > Hi Oliver,
> >
> > Thanks for the quick reply.
> >
> > Indeed i was referring to VRF-LITE
> >
> > In the cisco.com example, they gave this Router(config)# ip vrf
> > customer_a
> > Router(config-vrf)# rd 1:1    <----
> > Router(config-vrf)# route-target both 1:1  <---- Router(config)#
> > interface fastEthernet 0.1 Router(config-subif)# ip vrf forwarding
> > customer_a
> >
> > is there any specific reason why cisco recommends using "both"
> > (export/import) for its own RD ?
>
> the RD is not exported, the RT is. see answer to next question.
>
> Well, the "import" is not really needed in this specific case as there
> is no other VRF exporting routes with this route-target (so no point
> importing it).
>
> >
> > Oliver's example is here, but i would like to confirm if 1:100 is a
> > typo or should it be 1:1 (like its own RD?): ip vrf customer_A
> >  rd 1:1       <-----
> >  route-target export 1:100     <----
> >  route-target import 1:900
>
> RD and route-target are different things. They can be the same, but
they
> must not be (in an mpls-vpn, they usually aren't the same as the RD is
> unique per PE per VRF).
>
> > I wonder wondering if this is the correct place to post newbie
> > questions like these ?
> > Im a junior engineer in a singaporean isp, hoping to learn more
tricks
>
> > and tips in the field of IP planning :D
>
> well, I guess it's like all lists where folks help each other: If
people
> see that you haven't done your homework, you might not get a reply.
>
>        oli
>
>
> ------------------------------
>
> _______________________________________________
> cisco-nsp mailing list
> cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
>
> End of cisco-nsp Digest, Vol 70, Issue 57
> *****************************************
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> This email and any files transmitted with it are confidential and
intended
>  solely for the use of the individual or entity to whom they are
addressed.
> Please notify the sender immediately by email if you have received
this
> email by mistake and delete this email from your system. Please note
that
>  any views or opinions presented in this email are solely those of the
>  author and do not necessarily represent those of the organisation.
> Finally, the recipient should check this email and any attachments for
> the presence of viruses. The organisation accepts no liability for any
> damage caused by any virus transmitted by this email.
>
>
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/