[c-nsp] Inter VRF Routing help needed

[Andy Saykao]

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.