Hi Aman,
> 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.
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://github.com/osrg/gobgp/pull/1462
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://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
