Some update. FRR/Zebra supports this via ZEBRA_VRF_LABEL command in ZAPI version 5. See https://github.com/FRRouting/frr/issues/1759 for more details.
I have updated GoBGP code with support for ZAPI version 5. Subsequently, I have added code to add VRF label into MPLS forwarding table with the above command. It works as expected. To do this work, I created a branch off zclient-Enable_to_request_MPLS_label_range created by Iwase Yusuke (see the pull request at: https://github.com/osrg/gobgp/pull/1587). If this pull request gets accepted into the master branch, I can submit my changes as a pull request if there is interest. thx aman -----Original Message----- From: Iwase Yusuke [mailto:iwase.yusu...@gmail.com] Sent: Sunday, February 18, 2018 6:36 PM To: SHAIKH, AMAN (AMAN) <asha...@research.att.com> Cc: gobgp-devel@lists.sourceforge.net Subject: Re: [GoBGP-devel] MPLS label issue with VPNv4 routes Hi Aman, > Thanks for looking into FRR/Zebra. I'll open an issue with them about this, > > and we'll go from there. Thanks, I will watching on the issue you created on GitHub. > Do you know when your pull request > (https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_osrg_gobgp_pull_1587&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=_qcYvHss2I5JM-bLV-OJ7gfCVY_RT2CixyWc8X6q1GM&s=gxg7vN_Vh0_kMSjXhE0_T5AFFZngDYTgL8lLzN7IhtY&e= > ) > will be accepted? It's been open for 7 days now. Sorry, I don't know... it just seems to be under reviewing... Thanks, Iwase On 2018年02月16日 23:58, SHAIKH, AMAN (AMAN) wrote: > > Hi Iwase > > Thanks for looking into FRR/Zebra. I'll open an issue with them about this, > and we'll go from there. > > Do you know when your pull request > (https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_osrg_gobgp_pull_1587&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=_qcYvHss2I5JM-bLV-OJ7gfCVY_RT2CixyWc8X6q1GM&s=gxg7vN_Vh0_kMSjXhE0_T5AFFZngDYTgL8lLzN7IhtY&e= > ) will be accepted? It's been open for 7 days now. > > thx > aman > > -----Original Message----- > From: Iwase Yusuke [mailto:iwase.yusu...@gmail.com] > Sent: Thursday, February 15, 2018 11:34 PM > To: SHAIKH, AMAN (AMAN) <asha...@research.att.com> > Cc: gobgp-devel@lists.sourceforge.net > Subject: Re: [GoBGP-devel] MPLS label issue with VPNv4 routes > > Hi Aman, > > Thanks! That sounds great! > I look forward to your testing result! > > But... while I was reading the FRR/Zebra's codes, I found that Zebra does not > provide API for installing a route to decap MPLS label and forward it to VRF > like "ip -f mpls route add 80 dev blue"... > I found only API for swapping MPLS labels (ZEBRA_MPLS_LABELS_ADD) message. > Actually, it seems to be able to add routes to PUSH/POP MPLS label, but I > couldn't construct Zebra message for "<MPLS Label> dev <VRF>". > > Thanks, > Iwase > > > On 2018年02月15日 01:49, SHAIKH, AMAN (AMAN) wrote: >> >> Hi Iwase >> >> As I mentioned, I sent an e-mail to someone about this error: >> >>> [ashaikh@vsp-vpe-west ~]$ sudo ip route add vrf blue 172.16.0.1 >>> encap mpls 80 via 192.168.10.3 RTNETLINK answers: Network is >>> unreachable >> >> Here's his response: >> >> "Looks like the MPLS code is not handling recursive lookups - which it >> should. >> >> I'll work on patch when I get a few minutes; should be able to get to it by >> the end of this week" >> >> So, I'd suggest let's wait till I get his patch and get to try it out in my >> test-bed. If it works, things will be considerably simpler. >> >> aman >> >> -----Original Message----- >> From: Iwase Yusuke [mailto:iwase.yusu...@gmail.com] >> Sent: Tuesday, February 13, 2018 7:31 PM >> To: SHAIKH, AMAN (AMAN) <asha...@research.att.com> >> Cc: gobgp-devel@lists.sourceforge.net >> Subject: Re: [GoBGP-devel] MPLS label issue with VPNv4 routes >> >> Hi Aman, >> >> I really appreciate! >> I will also try them through sending message to FRR/Zebra. >> >> Thanks, >> Iwase >> >> >> On 2018年02月14日 04:10, SHAIKH, AMAN (AMAN) wrote: >>> >>> Hi Iwase >>> >>> I tried the following, but got an error: >>> [ashaikh@vsp-vpe-west ~]$ sudo ip route add vrf blue 172.16.0.1 >>> encap mpls 80 via 192.168.10.3 RTNETLINK answers: Network is >>> unreachable >>> >>> I'm going to ask someone who knows more about how MPLS and VRFs work on >>> Linux to see if there is some other way to make this work. >>> >>> aman >>> >>> -----Original Message----- >>> From: Iwase Yusuke [mailto:iwase.yusu...@gmail.com] >>> Sent: Tuesday, February 13, 2018 12:54 AM >>> To: SHAIKH, AMAN (AMAN) <asha...@research.att.com> >>> Cc: gobgp-devel@lists.sourceforge.net >>> Subject: Re: [GoBGP-devel] MPLS label issue with VPNv4 routes >>> >>> Hi Aman, >>> >>> Thank you for your confirmation! >>> >>> > --> This is definitely a possibility except you will have to consult >>> FRR/Zebra > to determine 'dev ens8' part, right? In any case, I will try >>> this out in my > testbed and let you know what happens. >>> >>> Oops, I mistook. I want to remove 'dev ens8' part too, because GoBGP is not >>> maintaining the info (or list) of the interfaces. Ideally, I want to push >>> routes with only BGP's next-hop like; >>> $ ip route show vrf blue ...<snip> >>> 172.16.0.1 encap mpls 80 via 192.168.10.3 >>> 192.168.1.0/24 encap mpls 80 via 192.168.10.3 >>> >>> If possible, I guess we can make the ZClient implementation keep >>> (relatively) simple. >>> >>> Thanks, >>> Iwase >>> >>> >>> On 2018年02月13日 11:17, SHAIKH, AMAN (AMAN) wrote: >>>> >>>> Hi Iwase >>>> >>>> Comments inline ... >>>> >>>> > This is perhaps a complicated transaction with FRR/Zebra. GoBGP >>>> will have to > do this transaction when it imports a VPNv4 route into a >>>> VRF. It will have to > instruct FRR/Zebra with two things: >>>> > - Encapsulate the route with label associated with it. >>>> > - Resolve the BGP next-hop in the default forwarding table even >>>> though the > route is installed in the blue VRF. >>>> > >>>> > Let me know what your thoughts are. >>>> >>>> Let me clear my head, first. >>>> You mean the current GoBGP "additionally" need to install two >>>> route; >>>> >>>> 1. forwarding MPLS labeled traffic to VRF; >>>> $ ip -f mpls route show ...<snip> >>>> 80 dev blue >>>> >>>> --> Without this route, MPLS labeled traffic coming from the backbone will >>>> be dropped by the PE. This route tells PE to pop VRF-label (80) from the >>>> packet and consult the forwarding table of blue VRF for the IP destination >>>> address stored in the IP portion of the packet. >>>> >>>> 2. pushing traffic from ECs to MPLS backbone; >>>> $ ip route show vrf blue ...<snip> >>>> 172.16.0.1 encap mpls 19/80 via 10.202.0.8 dev ens8 >>>> 192.168.1.0/24 encap mpls 19/80 via 10.202.0.8 dev ens8 >>>> >>>> For the "1." route, I guess we can install it when creating VRF, but not >>>> yet implemented. >>>> >>>> --> Yes, agree with you. >>>> >>>> For the "2." route, related to the latter point you mentioned, can we >>>> specify them like the following? >>>> $ ip route show vrf blue ...<snip> >>>> 172.16.0.1 encap mpls 80 via 192.168.10.3 dev ens8 >>>> 192.168.1.0/24 encap mpls 80 via 192.168.10.3 dev ens8 >>>> >>>> --> This is definitely a possibility except you will have to consult >>>> FRR/Zebra to determine 'dev ens8' part, right? In any case, I will try >>>> this out in my testbed and let you know what happens. >>>> >>>> In other words, I want to avoid resolving the outer label and MPLS's >>>> next-hop from the BGP's next-hop (if we can). I guess it helps the >>>> implementation simple. >>>> >>>> --> Yes, I understand. >>>> >>>> I took a (little) look at FRRouting implementation, bgpd does not seem to >>>> resolve the outer label and MPLS's next-hop from the BGP's next-hop, >>>> because it does not call "*_NEXTHOP_LOOKUP" messages. >>>> >>>> --> I'm not surprised FRR's bgpd does not handle this. It's fairly >>>> complicated given multi-step resolution of BGP next-hop along with >>>> multiple VRFs. >>>> >>>> aman >>>> ------------------------------------------------------------------- >>>> - >>>> - >>>> - >>>> -------- Check out the vibrant tech community on one of the world's >>>> most engaging tech sites, Slashdot.org! >>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashd >>>> o >>>> t >>>> & >>>> d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF >>>> 4 >>>> _ >>>> J >>>> M0AhcKK4Y&m=rp0W2LFXGi63VxNF9MB34SGLxRD2n_CAypR-qqMoDEI&s=f1tsvXH69 >>>> A >>>> r >>>> 9 >>>> Y3qVCi94zCmOGEzTWyBFLH31rrZEscY&e= >>>> _______________________________________________ >>>> gobgp-devel mailing list >>>> gobgp-devel@lists.sourceforge.net >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourcefo >>>> r >>>> g >>>> e >>>> .net_lists_listinfo_gobgp-2Ddevel&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg >>>> & >>>> r >>>> = >>>> I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=rp0W2LFXGi63VxNF9MB34 >>>> S >>>> G >>>> L >>>> xRD2n_CAypR-qqMoDEI&s=uHUJBsM7DRJzTnA7T41g0oWQE0Ovu50Pq7gSubJdrCs&e >>>> = >>>> >>> -------------------------------------------------------------------- >>> - >>> - >>> -------- Check out the vibrant tech community on one of the world's >>> most engaging tech sites, Slashdot.org! >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdo >>> t >>> & >>> d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4 >>> _ >>> J >>> M0AhcKK4Y&m=i8vqRael0CLkyTAEGntuf6N-vnFvflmoA6h5_g7Pnn4&s=_jBM2i2ugJ >>> 9 >>> t >>> ATuGK_BKOc7kG33o7HRIbaLO43S3v6o&e= >>> _______________________________________________ >>> gobgp-devel mailing list >>> gobgp-devel@lists.sourceforge.net >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourcefor >>> g >>> e >>> .net_lists_listinfo_gobgp-2Ddevel&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg& >>> r >>> = >>> I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=i8vqRael0CLkyTAEGntuf6 >>> N >>> - >>> vnFvflmoA6h5_g7Pnn4&s=ID_j23zA8zV3aMKpozvGWGF6OWVHDmNHhIvr89tma9o&e= >>> >> --------------------------------------------------------------------- >> - >> -------- Check out the vibrant tech community on one of the world's >> most engaging tech sites, Slashdot.org! >> https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot >> & >> d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_ >> J >> M0AhcKK4Y&m=g8q0_Iq5qFpomdaNRZFrqXJNsRqEsameFh8tyA9xwgY&s=h-Chg4H5KU7 >> k >> fVWkyna2w2OyL4F2Kf955Ls-xpZlHns&e= >> _______________________________________________ >> gobgp-devel mailing list >> gobgp-devel@lists.sourceforge.net >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforg >> e >> .net_lists_listinfo_gobgp-2Ddevel&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r >> = >> I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=g8q0_Iq5qFpomdaNRZFrqXJ >> N >> sRqEsameFh8tyA9xwgY&s=2364nvVOQmDce5OmUPVq0WS3JEw6w5m10WbOpvPl0BA&e= >> > ---------------------------------------------------------------------- > -------- Check out the vibrant tech community on one of the world's > most engaging tech sites, Slashdot.org! > https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot& > d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_J > M0AhcKK4Y&m=_qcYvHss2I5JM-bLV-OJ7gfCVY_RT2CixyWc8X6q1GM&s=nAV6J6d9V96L > EPFdD2kR0pkzfthwof6E4hBRwWerXmE&e= > _______________________________________________ > gobgp-devel mailing list > gobgp-devel@lists.sourceforge.net > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge > .net_lists_listinfo_gobgp-2Ddevel&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r= > I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=_qcYvHss2I5JM-bLV-OJ7gfC > VY_RT2CixyWc8X6q1GM&s=-JPkXz8MjptpH9tAQwZuEnFHMLAWjfi0jivtixvG0Ic&e= > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ gobgp-devel mailing list gobgp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gobgp-devel