Re: A noobs thoughts on RDs and RTs

From: Carlos G Mendioroz <tron_at_huapi.ba.ar>
Date: Tue, 10 Apr 2012 08:00:28 -0300

John,
there are some wordings that make me feel uneasy with your description.

Disclaimer: I'm very picky with words, and some (many!) get irritated
because of this, and treat the issue with disdain (usually comes wiht
the phrase "this is just semantics" or the like). Well, semantics is
all we have to convey meaning.

Please read inline:

John Neiberger @ 10/04/2012 01:20 -0300 dixit:
> This is sort of an addendum to the discussion a week or so ago about
> the difference between route targets and route descriptors. Now that
> I've had a chance to study them a bit more I thought I would check to
> see if my understanding is correct. As I mentioned in the other
> thread, I always like to approach learning and teaching from this
> standpoint: what problem are we trying to solve? We have two primary
> problems to solve, but it's easier to them once you've encountered
> them.
>
> I'll assume you have a basic understanding of VRFs. Let's assume you

It's great to have a small description just to make sure we do.
We can call it a "customer dedicated virtual router" ?

> have two customers assigned to two VRFs and they have overlapping IP
> address space, e.g. 10/8. You configure your VRFs and then (let's

Note that you are talking about VRFs like they span multiple places.
They do not. Would the phrase "you have two customer with two routers"
make sense ?

> pretend) you configure iBGP and somehow start passing routes around
> your core network.

One of the beauties of MPLS VPNs is that the core does not carry
customer routes, keep that in mind, they are just at the edge (PEs).

>When a remote iBGP peer receives a 10.0.0.0/8 route
> twice, what is it supposed to do with them? You know that they're from
> two different customers, but how is the router supposed to know that?
> That's where the Route Distinguisher comes in. It is a tag of sorts
> that you prepend to the routes from your VRFs so that receiving
> routers know that they're to be treated differently. They are, in
> fact, different routes.

Hmm, you start by saying "different customers" but RDs are not used to
get customers appart. In fact, they could have different RDs and belong
to the same customer.
And RDs are not tags. A tag is something you add to an object. The RD
prepended to an IPv4 route makes a new object alltogether: a VPNv4 route.

> Okay, the router has received them. Now what is it supposed to do with
> them? You may have the same two VRFs configured on this receiving
> router, but is the router just supposed to automatically put all
> routes with matching route descriptors into the same VRFs? Sure,

You don't have the same VRFs. Just because my brother's name is the
same as your brother, does not make him ralated in any way!!!

The VRF name has local significance, and it's an aid to understand
simple VPNs. And VRFs are local in all respects. If there's a relation
between two VRFs, that's because a design was made and different routers
are configured to make that happen.

> that's one way it could work. But what happens if down the road you
> need to share some routes between customers? How could you control
> which VRFs get which routes? Or what if you have a load-balancing
> situation where you have routes from the same customer being
> advertised with two different Route Distinguishers?
>
> Well, my friends, that's where the Route Target comes into play, and
> even though so many examples of RTs and RDs make them the same, they
> have nothing whatsoever to do with each other. The RT is a BGP
> community that rides along with your route advertisements that tells
> the receiving router which VPN they belong to. That gives you some
> serious flexibility.

Hehe, this is quite right and, in my view, hides the root of many
understanding problems with this subject: what is a VPN?
Problem being, we are used to think that a VPN is a VPN: Virtual
Private Network. As such, if A is "networked" to B and B is "networked"
to C then A is networked to C, which is false sometimes.
Also, a router can be connected to many networks, something that was
quite common when IPX and Appletalk were around. Now a VRF (a router)
can be connected to multiple VPNs. Nothing new, but confusing.

So again, the main problem as I see it is that we all talk about VPNs
without properly describing what we mean by that. We do with it most of
the time without much problems though.

>
> But wait. Why do we need two different types of "labels" to
> differentiate between these routes. Now that we have a Route Target,
> why can't we just use that? Well, because the RT is a community
> attribute. It is not prepended to the beginning of the route like the
> Route Distinguisher. If you take away the RD, you're back to a
> situation where the receiving router doesn't know that these routes
> came from different customers.

... "come from different networks" sounds better to me.

> It sees the exact same routes with
> different route targets. That might confuse it.

Well, it (the router routing protocol) would confuse them (the routes),
and do what routing protocols do: choose the best one and forget the other.

> So, the RD does NOTHING but distinguish routes. Clever, huh? It makes
> them unique within your iBGP network. The RT is what tells the
> receiving router which VPN those routes belong to, which gives you
> much more flexibility with regard to importing and exporting.
>
> So, you RD/RT experts, is that basically correct?

You tell me. If what I wrote sounds to you like "yes, that's what I
meant" then yes. If something generated a reaction of "what? wait a
moment!" then may be not.

-Carlos

>
> Thanks,
> John
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net
Received on Tue Apr 10 2012 - 08:00:28 ART

This archive was generated by hypermail 2.2.0 : Tue May 01 2012 - 08:20:45 ART