Hi Iwase Some update on this front. I had discussion about this with FRR/Zebra. See https://github.com/FRRouting/frr/issues/1839. 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_slashdot >> & >> d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_ >> J >> M0AhcKK4Y&m=rp0W2LFXGi63VxNF9MB34SGLxRD2n_CAypR-qqMoDEI&s=f1tsvXH69Ar >> 9 >> Y3qVCi94zCmOGEzTWyBFLH31rrZEscY&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=rp0W2LFXGi63VxNF9MB34SG >> 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=_jBM2i2ugJ9t > ATuGK_BKOc7kG33o7HRIbaLO43S3v6o&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=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
