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 <michaelewal...@gmail.com> 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 <hayabusa...@gmail.com> > 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 <rob...@raszuk.net> 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 <michaelewal...@gmail.com> >>> 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 and new label 2. >>>> >>>> R1-----eBGP- VPNv4-----R2-----iBGP VPNv4-----R3 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org >>> 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: gyan.s.mis...@verizon.com >> >> 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: gyan.s.mis...@verizon.com www.linkedin.com/in/networking-technologies-consultant
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
