Hi Satya, I believe the address Michael is using in the route-map to set nh is one of the local addresses on the very ASBR.
Thx, R. On Thu, Dec 12, 2019 at 8:25 PM Satya Mohanty (satyamoh) <[email protected]> wrote: > Hi, > > > > If the next-hop is set to some third-party device at the option-B ASBR and > a new label is advertised, then we have to make sure that at that > third-party device, the particular prefix is in fact bound to that > particular label. Therefore, in addition to setting the next-hop at the > ASBR there needs to be a way to specify the particular label also. > > > > Otherwise just using any dynamic label will not work. > > > > Thanks, > > --Satya > > > > > > *From: *BESS <[email protected]> on behalf of Gyan Mishra < > [email protected]> > *Date: *Thursday, December 12, 2019 at 11:01 AM > *To: *michael walden <[email protected]> > *Cc: *"[email protected]" <[email protected]>, Robert Raszuk <[email protected]> > *Subject: *Re: [bess] RFC 8277 > > > > > > > > I can try it out in VIRL. > > > > What version of XR or XE are you running? > > > > On Thu, Dec 12, 2019 at 1:52 PM michael walden <[email protected]> > wrote: > > Thank you for the responses. This is specifically not using next hop self > to change the next hop, but using a route map or RPL to set next hop to a > specific IP value such as below. I realize this probably isn't a common > configuration. > > > > route-map NH permit 10 > match ip address prefix-list ONE > set ip next-hop x.x.x.x > > > > route-policy NH > if destination in (1.1.1.1/32) then > set next-hop x.x.x.x > > > > On Thu, Dec 12, 2019 at 12:48 PM Gyan Mishra <[email protected]> > wrote: > > > > > > With option b since the LSP is segmented into 3 segments > > > > Left side Rx to R1 -ibgp > > Middle R1 to R2 - ebgp vpnv4 > > Right side R2 to R3 - ibgp > > > > So for the LSP to be segmented in opt b for it to work properly what is > required is either next-hop-self on the ibgp peer so the rewrite happens > forcing the label to change so the lsp is segmented on left side and right > side from the middle. The reason also for the segmentation in opt B is we > are not importing the SP loops between each other as done with opt c so > the segmentation of the lsp has to happen for opt b to work. > > > > If you are doing this on Cisco XR it requires next hop static /32 route > for MPLS forwarding to happen on the ebgp vpnv4 session where with XE > automatically installs “MPLS forwarding” when ebgp vpnv4 is configured. > > > > If the rewrite is not happening to segment the lsp generate a new label > then sounds like you are hitting a big. > > > > The inter as opt a b c ab are all IETF standards and the functionality and > behavior should be the same across all vendors. > > > > Cheers, > > > > Gyan > > > > On Thu, Dec 12, 2019 at 11:55 AM Robert Raszuk <[email protected]> wrote: > > /* replacing IETF mailer with BESS */ > > > > Hi Michael, > > > > Clearly you have discovered a bug in first implementation. Second > implementation "other platform" works correctly. > > > > I assume you are doing next hop self on R2. Advertising labels have only > local significance to a box which is listed as next hop in the NLRIs. > > > > Btw this behaviour did not really change from original RFC3107 so it is > quite surprising you would still be running into such issues. > > > > Thx, > R. > > > > On Thu, Dec 12, 2019 at 5:27 PM michael walden <[email protected]> > wrote: > > > Regarding RFC 8277 Section 3.2.2 > 3.2.2. When the Next Hop Field Is Changed > > If the Network Address of Next Hop field is changed before a SAFI-4 > or SAFI-128 route is propagated, the Label field(s) of the propagated > route MUST contain the label(s) that is (are) bound to the prefix at > the new next hop. > > > "the Label field(s) of the propagated route MUST contain the label(s) that > is (are) bound to the prefix at the new next hop." > > This specification should apply when the next hop field of the route is > changed by any means such as route map, route policies, or next-hop-self > and propagated? > > I've experienced differing behaviors between platforms as to whether or > not a the label is changed when the next hop field is changed with a route > map or route policy. > > For example below inter-as option b R2 receives VPNv4 route 1.1.1.1/32 > with label 1 from R1. R2 changes the next hop field with an outbound route > policy but doesn't replace the label before propagating the route to R3. > R3 receives VPNv4 route 1.1.1.1/32 and original label 1 breaking the LSP. > > R1-----eBGP- VPNv4-----R2-----iBGP VPNv4-----R3 > > > However on other platforms inter-as option b R2 receives VPNv4 route > 1.1.1.1/32 with label 1 from R1. R2 changes the next hop field with an > outbound route policy and does replace the label before propagating the > route to R3. R3 receives VPNv4 route 1.1..1.1/32 <http://1.1.1.1/32> and > new label 2. > > R1-----eBGP- VPNv4-----R2-----iBGP VPNv4-----R3 > > > > > > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess > > -- > > Gyan S. Mishra > > IT Network Engineering & Technology > > Verizon Communications Inc. (VZ) > > 13101 Columbia Pike > <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> > FDC1 3rd Floor > > Silver Spring, MD 20904 > > United States > > Phone: 301 502-1347 > > Email: [email protected] > > www.linkedin.com/in/networking-technologies-consultant > > > > -- > > Gyan S. Mishra > > IT Network Engineering & Technology > > Verizon Communications Inc. (VZ) > > 13101 Columbia Pike FDC1 3rd Floor > > Silver Spring, MD 20904 > > United States > > Phone: 301 502-1347 > > Email: [email protected] > > www.linkedin.com/in/networking-technologies-consultant > > >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
