Hi Iwase I have started by updating the Nexthop structure and its serialization and decoding in zebra/zapi.go file.
Will keep you posted. aman -----Original Message----- From: Iwase Yusuke [mailto:iwase.yusu...@gmail.com] Sent: Monday, March 12, 2018 10:12 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, > Some update on this front. I had discussion about this with FRR/Zebra. See > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_FRRouting_frr_issues_1839&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=L-ZNkWOyCdQLM8o1BBrdogzqE44x9z8ZbJt2GWhLdM4&s=7_-zJFmwWinZODdWKNGdxs1zdtfwWTnHHM9U_hdbho0&e= > . The upshot is that one could add > a VPNv4 route of this form " > prefix=172.16.0.1/32 label=80 > next-hop=192.168.10.3" via Zebra's > ZEBRA_ROUTE_ADD message to a VRF table. The > next-hop can belong to > another VRF (usually default), and Zebra can handle > recursive look-up of > the next-hop. However, this requires usage of ZAPI > version 5. Thanks for your information! I understood with ZAPI version 5, Zebra can resolve recursive next-hop and GoBGP does not require to resolve it itself. > I can go ahead and add this functionality in my ZAPI_5 branch. However, > > looking through the code, I wasn't sure where I'd add a call to Zebra since > my > understanding of GoBGP code is limited. Since you are more familiar > with the > code, can you suggest where the required changes should go? Hmmmm... it is depending on what exactly you want to know though, most of functionalities as a Zebra Client are implemented on "server/zclient.go", and the ZAPI message parsers are on "zebra/zapi.go". Others, like "config" and "server" packages, do passing options or validating version range for example. I hope the pull request #1462 will be of some help for you. https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_osrg_gobgp_pull_1462&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=L-ZNkWOyCdQLM8o1BBrdogzqE44x9z8ZbJt2GWhLdM4&s=vI86K3JczHwtRJEO5uBhvVBZeDftdLpvP1D1IlcEhBk&e= Thanks, Iwase On 2018年03月10日 04:40, SHAIKH, AMAN (AMAN) wrote: > > Hi Iwase > > Some update on this front. I had discussion about this with FRR/Zebra. See > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_FRRouting_frr_issues_1839&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=L-ZNkWOyCdQLM8o1BBrdogzqE44x9z8ZbJt2GWhLdM4&s=7_-zJFmwWinZODdWKNGdxs1zdtfwWTnHHM9U_hdbho0&e= > . The upshot is that one could add a VPNv4 route of this form " > prefix=172.16.0.1/32 label=80 next-hop=192.168.10.3" via Zebra's > ZEBRA_ROUTE_ADD message to a VRF table. The next-hop can belong to another > VRF (usually default), and Zebra can handle recursive look-up of the > next-hop. However, this requires usage of ZAPI version 5. > > I can go ahead and add this functionality in my ZAPI_5 branch. However, > looking through the code, I wasn't sure where I'd add a call to Zebra since > my understanding of GoBGP code is limited. Since you are more familiar with > the code, can you suggest where the required changes should go? > > thx > aman > > > > -----Original Message----- > From: SHAIKH, AMAN (AMAN) > Sent: Friday, March 2, 2018 7:59 PM > To: 'iwase.yusu...@gmail.com' <iwase.yusu...@gmail.com> > Cc: 'gobgp-devel@lists.sourceforge.net' > <gobgp-devel@lists.sourceforge.net> > Subject: RE: [GoBGP-devel] MPLS label issue with VPNv4 routes > > > Hi Iwase > > I heard back from the person who'd promised to look into patching Linux > kernel. He found that Linux kernel in general does not allow recursive > look-up of next-hops. So, the fix required is much bigger than he'd > originally thought, and could take several months before he is able to > prepare the fix. > > I think we'll have to try to make this work through FRR/Zebra. I will think > some more about this. > > aman > > -----Original Message----- > From: SHAIKH, AMAN (AMAN) > Sent: Wednesday, February 14, 2018 11:50 AM > To: gobgp-devel@lists.sourceforge.net > Subject: RE: [GoBGP-devel] MPLS label issue with VPNv4 routes > > > 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_slashdo >>> t >>> & >>> d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4 >>> _ >>> J >>> M0AhcKK4Y&m=rp0W2LFXGi63VxNF9MB34SGLxRD2n_CAypR-qqMoDEI&s=f1tsvXH69A >>> r >>> 9 >>> Y3qVCi94zCmOGEzTWyBFLH31rrZEscY&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=rp0W2LFXGi63VxNF9MB34S >>> 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_slashdot >> & >> d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_ >> J >> M0AhcKK4Y&m=i8vqRael0CLkyTAEGntuf6N-vnFvflmoA6h5_g7Pnn4&s=_jBM2i2ugJ9 >> t >> ATuGK_BKOc7kG33o7HRIbaLO43S3v6o&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=i8vqRael0CLkyTAEGntuf6N >> - >> vnFvflmoA6h5_g7Pnn4&s=ID_j23zA8zV3aMKpozvGWGF6OWVHDmNHhIvr89tma9o&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
