Hi Aman, Thanks a lot for your information!
> I think we'll have to try to make this work through FRR/Zebra. I will think > some more about this. Yeah, I agree with you. Doing look up recursive next-hops will be a heavy burden for GoBGP... Thanks, Iwase On 2018年03月03日 09:59, SHAIKH, AMAN (AMAN) wrote: > > 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
