Subject: Re: Doubt in BGP for L3 VPNs

From: John Smith <[email-masked]>
Date: Thu, 14 Apr 2005 01:44:37 +0100 (BST)

Hi Ron,

This is the problem.

PEy has an MPLS tunnel till PEz and not till PEx. Routes recieved from PEx have PEx as
the next-hop. BGP running on PEy will not be able to recursivly resolve the next-hops for
the routes to PEx and will not use them. However, if we change the nexthop to that of PEz
then PEy will install the routes. 

Its the same logic that exists in ordinary RRs. I am just trying to see if it will work
for L3 VPNs OR as you say, it may be making no sense at all!

Thanks,
John

--- Ronald Bonica <[email-masked]> wrote:
> Hi John,
> 
> Normally, route reflectors don't set next-hop-self. If you let PEz relay 
> the UPDATE without modifying it at all, things will work fine.
> 
> Maybe I am misunderstanding point of your question?
> 
>                                          Ron
> 
> 
> John Smith wrote:
> > Hi,
> > 
> > PEx -- PEz -- PEy
> > 
> > This is in the context of L3 VPNs. PEz is a BGP route reflector connected to two
> clients
> > PEx and PEy (its also connected to other PE routers which i have omitted for the sake
> of
> > clarity).
> > 
> > By default, PEy recieves all BGP UPDATEs from PEx which have PEx as the NEXT_HOP.
> This
> > happens for the NEXT_HOP attribute in the BGP UPDATE message and also for the
> next-hop
> > that is encoded inside MP_REACH_NLRI. This way, PEy knows that it needs to put an
> outer
> > label that corresponds to the router PEx.
> > 
> > Now, we want all the BGP labelled packets to terminate at the RR viz PEz. So, we
> > configured next-hop-self on the RR thinking that it will change the NEXT_HOP path
> > attribute carried in the BGP UPDATE message and that carried inside the MP_REACH_NLRI
> to
> > that of the PEz.
> > 
> > Is this correct? We find that the outer NEXT_HOP gets converted to that of the RR,
> but
> > the internal still points to PEx. Is this vendor behavior incorrect or is there a
> flaw in
> > our understanding?
> > 
> > Thanks,
> > John
> > 
> > Send instant messages to your online friends http://uk.messenger.yahoo.com 
> > 
> 
> 

Send instant messages to your online friends http://uk.messenger.yahoo.com

---

From: "Rajiv Asati \(rajiva\)" <[email-masked]>
Date: Wed, 13 Apr 2005 20:51:23 -0400

John,

> By default, PEy recieves all BGP UPDATEs from PEx which have 
> PEx as the NEXT_HOP. This happens for the NEXT_HOP attribute 
> in the BGP UPDATE message and also for the next-hop that is 
> encoded inside MP_REACH_NLRI. This way, PEy knows that it 

When the UPDATE carries MP_REACH_NLRI, the NEXT_HOP attribute should not
be carried since the NEXT_HOP information is encoded inside the
MP_REACH_NLRI. This is needed so that the same UPDATE can pack multiple
MP_REACH_NLRI (that may have different NEXT_HOPs). Please take a look at
the RFC2283.

> Now, we want all the BGP labelled packets to terminate at the 
> RR viz PEz. 

Could you please explain "why" ?

> Is this correct? We find that the outer NEXT_HOP gets 
> converted to that of the RR, but the internal still points to 
> PEx. Is this vendor behavior incorrect or is there a flaw in 
> our understanding?

By definition, the RR is not supposed to change the NEXT_HOP.

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of John Smith
> Sent: Wednesday, April 13, 2005 8:18 PM
> To: [email-masked]
> Subject: Doubt in BGP for L3 VPNs
> 
> Hi,
> 
> PEx -- PEz -- PEy
> 
> This is in the context of L3 VPNs. PEz is a BGP route 
> reflector connected to two clients PEx and PEy (its also 
> connected to other PE routers which i have omitted for the 
> sake of clarity).
> 
> By default, PEy recieves all BGP UPDATEs from PEx which have 
> PEx as the NEXT_HOP. This happens for the NEXT_HOP attribute 
> in the BGP UPDATE message and also for the next-hop that is 
> encoded inside MP_REACH_NLRI. This way, PEy knows that it 
> needs to put an outer label that corresponds to the router PEx.
> 
> Now, we want all the BGP labelled packets to terminate at the 
> RR viz PEz. So, we configured next-hop-self on the RR 
> thinking that it will change the NEXT_HOP path attribute 
> carried in the BGP UPDATE message and that carried inside the 
> MP_REACH_NLRI to that of the PEz. 
> 
> Is this correct? We find that the outer NEXT_HOP gets 
> converted to that of the RR, but the internal still points to 
> PEx. Is this vendor behavior incorrect or is there a flaw in 
> our understanding?
> 
> Thanks,
> John
>

---

From: "Rajiv Asati \(rajiva\)" <[email-masked]>
Date: Wed, 13 Apr 2005 23:37:56 -0400

John,

As long as RR can change the NEXT_HOP within MP_REACH_NLRI, associate a
new label with the NLRI, and install the label mapping in the MPLS
forwarding table, it should work fine. It puts the RR in the forwarding
path of VPN traffic.

I do have a follow-up Q on the background though. Please see inline...

> PEx -- RR -- PEy
> 
> PEy does not have a MPLS tunnel till PEx. It has it only till 
> the RR. In this case, PEy will not be able to install routes 
> learnt from PEx (using 2547) as it will not be able to 
> resolve the next-hop. In such cases, an admin can manually 

So, PEx has an LSP to RR, and so does PEy.
(Just having the LSP tunnel on one segment will not provide the MPLS
path between PEs.)
Just curious What's the reason behind PEs not learning each other's
route and/or label ?

Cheers,
Rajiv

> From: John Smith [mailto:[email-masked]] 
> Sent: Wednesday, April 13, 2005 10:09 PM
> To: Rajiv Asati (rajiva); [email-masked]
> Subject: RE: Doubt in BGP for L3 VPNs
> 
> Hi Rajiv,
> 
> > When the UPDATE carries MP_REACH_NLRI, the NEXT_HOP 
> attribute should 
> > not be carried since the NEXT_HOP information is encoded inside the 
> > MP_REACH_NLRI. This is needed so that the same UPDATE can pack 
> > multiple MP_REACH_NLRI (that may have different NEXT_HOPs). Please 
> > take a look at the RFC2283.
> 
> I understand the point that NEXT_HOP is not mandatory when we 
> have MP_REACH_NLRI path attribute, but there are a lot of 
> implementations in the wild that do advertise the NEXT_HOP 
> nevertheless. Any sane implementation will NOT get bothered 
> with a NEXT_HOP in the UPDATE message when there are only 
> multiprotocol NLRIs to process.
> 
> > 
> > > Now, we want all the BGP labelled packets to terminate at 
> the RR viz 
> > > PEz.
> > 
> I did that in my other mail. I'll do it once more.
> 
> PEx -- RR -- PEy
> 
> PEy does not have a MPLS tunnel till PEx. It has it only till 
> the RR. In this case, PEy will not be able to install routes 
> learnt from PEx (using 2547) as it will not be able to 
> resolve the next-hop. In such cases, an admin can manually 
> set the next-hop-self on RR so that RR sets the NEXT_HOP to 
> itself in all the MPBGP NLRIs that it advertises to PEy. PEy 
> will now be able to accept the L3 VPN prefixes because the 
> next-hop in MP_REACH_NLRI is resolvable.
> 
> 
> > 
> converted to 
> > > that of the RR, but the internal still points to PEx. Is 
> this vendor 
> > > behavior incorrect or is there a flaw in our understanding?
> > 
> But there is nothing that forbids it from doing that! In 
> fact, there could be scenarios when it becomes vital for the 
> RR to do that. One case which i can think of at the top of my 
> head right now is when you want to enforce the RR to come in 
> the forwarding path.
> There could be zillion reasons why you may want that to 
> happen, security, QoS, predictability in the path being taken 
> in case you have equal cost BGP routes originating from your 
> behind, etc.
> 
> Thanks,
> John
> 
> > 
> > Cheers,
> > Rajiv
> > 
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of John Smith
> > > This is in the context of L3 VPNs. PEz is a BGP route reflector 
> > > connected to two clients PEx and PEy (its also connected 
> to other PE 
> > > routers which i have omitted for the sake of clarity).
> > > 
> > > By default, PEy recieves all BGP UPDATEs from PEx which 
> have PEx as 
> > > the NEXT_HOP. This happens for the NEXT_HOP attribute in the BGP 
> > > UPDATE message and also for the next-hop that is encoded inside 
> > > MP_REACH_NLRI. This way, PEy knows that it needs to put an outer 
> > > Now, we want all the BGP labelled packets to terminate at 
> the RR viz 
> > > PEz. So, we configured next-hop-self on the RR thinking 
> that it will 
> > > change the NEXT_HOP path attribute carried in the BGP 
> UPDATE message 
> > > and that carried inside the MP_REACH_NLRI to that of the PEz.
> > > 
> converted to 
> > > that of the RR, but the internal still points to PEx. Is 
> this vendor 
> > > behavior incorrect or is there a flaw in our understanding?
> > > 
> > > Thanks,
> > > John
> > >

---

From: "Steve Yao" <[email-masked]>
Date: Mon, 18 Apr 2005 15:04:42 -0500

Sylvia,

Yes. But in order to get to the VRF at RR, you need to have
the label allocated by the RR instead of a label that's allocated
by a PE and "reflected" by the RR to another PE.

Steve

-----Original Message-----
From: Spice Sylvia [mailto:[email-masked]]
Sent: Monday, April 18, 2005 2:23 PM
To: [email-masked]
Subject: RE: Doubt in BGP for L3 VPNs

Steve,

This is the one case whose behaviour I am trying to
clarify.

Take the case where the RR acts as both the P and PE
router.
The same RR can be an PE+transit for some customer
scenarios, the label mapping can be carried by BGP for
both cases.

for example:
            CE     CE 
             |      |
            PE     PE
             |      |
CE---PE-----RR-----RR----PE--CE
             |      |
            CE     CE

This CEs all belong to the same VPN. Rather than use a
seperate mechanism to signal a P2P LSP across PEs, let
BGP carry the association, by mapping traffic/prefixes
to the appropriate customer VRFs.

You agree that the VRFs in the middle on the RRs has
to have VPN routes of all PEs in that VPN?

------------------------------------------------------