Hi Aman,
Great! Thanks a lot!
Hmmm... more things seem to be required than I guessed...
> 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
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.
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
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.
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.
Thanks,
Iwase
On 2018年02月13日 06:11, SHAIKH, AMAN (AMAN) wrote:
Hi Iwase
Looks like you have submitted the MPLS range allocation from FRRouting as a
pull request (https://github.com/osrg/gobgp/pull/1587). That's great. Let's
hope it gets accepted.
As I'd promised here's a description of routes I expect in Linux kernel
forwarding table with BGP/MPLS VPNs:
I'll focus on one PE which receives two routes from its adjacent CE which are installed
in "blue" VRF:
[ashaikh@vsp-vpe-west ~]$ gobgp vrf blue rib
Network Next Hop AS_PATH Age
Attrs
....<snip>....
172.16.0.2/32 10.200.0.2 65001 00:49:37
[{Origin: i} {Med: 0}]
192.168.0.0/24 10.200.0.2 65001 00:49:37
[{Origin: i} {Med: 0}]
...<snip>...
Routes 172.16.0.2/32 and 192.168.0.0/24 are received from the CE (next-hop
10.200.0.2 is the interface address of the CE).
These two routes are installed in the Linux kernel's forwarding table for blue
VRF:
[ashaikh@vsp-vpe-west ~]$ ip route show vrf blue unreachable default metric
4278198272
10.200.0.0/16 dev ens6 proto kernel scope link src 10.200.0.3
172.16.0.2 via 10.200.0.2 dev ens6 proto zebra metric 20
192.168.0.0/24 via 10.200.0.2 dev ens6 proto zebra metric 20
These two routes are assigned MPLS label (for blue VRF) from the range obtained
from FRR/Zebra (thanks to your patch), before they're sent to the
route-reflector.
[ashaikh@vsp-vpe-west ~]$ gobgp global rib -a vpnv4
Network Labels Next Hop AS_PATH
Age Attrs
...<snip>...
*> 100:1:172.16.0.2/32 [80] 10.200.0.2 65001
01:10:47 [{Origin: i} {Med: 0} {Extcomms: [100:1]}]
*> 100:1:192.168.0.0/24 [80] 10.200.0.2 65001
01:10:47 [{Origin: i} {Med: 0} {Extcomms: [100:1]}]
...<snip>...
However, no route is installed in the default routing table for data-traffic
coming in with label 80. I'd expect a route of the following form in the Linux
forwarding table:
[ashaikh@vsp-vpe-west ~]$ ip -f mpls route show ...<snip>
80 dev blue
This route will allow vsp-vpe-west to accept any packets with MPLS label 80
coming from the service provider backbone, pop the label and transfer the
packet to the blue VRF forwarding table on the PE for subsequent forwarding to
the CE.
Next, let us focus on routes received from another PE (via the backbone).
[ashaikh@vsp-vpe-west ~]$ gobgp global rib -a vpnv4
Network Labels Next Hop AS_PATH
Age Attrs
*> 100:1:172.16.0.1/32 [80] 192.168.10.3 65001
01:11:33 [{Origin: i} {Med: 0} {LocalPref: 100} {Originator: 10.203.0.6}
{ClusterList: [192.168.0.1]} {Extcomms: [100:1]}]
*> 100:1:172.16.0.2/32 [80] 10.200.0.2 65001
01:15:30 [{Origin: i} {Med: 0} {Extcomms: [100:1]}]
*> 100:1:192.168.0.0/24 [80] 10.200.0.2 65001
01:15:30 [{Origin: i} {Med: 0} {Extcomms: [100:1]}]
*> 100:1:192.168.1.0/24 [80] 192.168.10.3 65001
01:11:33 [{Origin: i} {Med: 0} {LocalPref: 100} {Originator: 10.203.0.6}
{ClusterList: [192.168.0.1]} {Extcomms: [100:1]}]
The first and fourth routes above are received from another PE. The next-hop
(192.168.10.3) is the loopback of the remote PE which can be reached via an
MPLS LSP as shown below. (Note that the remote PE (running GoBGP) has also
assigned a label of 80 to both its routes.)
[ashaikh@vsp-vpe-west ~]$ ip route show
...<snip>...
192.168.10.3 encap mpls 19 via 10.202.0.8 dev ens8 proto zebra metric 20
These two routes are also imported into the blue VRF RIB by GoBGP:
[ashaikh@vsp-vpe-west ~]$ gobgp vrf blue rib
Network Next Hop AS_PATH Age
Attrs
172.16.0.1/32 192.168.10.3 65001 01:14:37
[{Origin: i} {Med: 0} {LocalPref: 100} {Originator: 10.203.0.6} {ClusterList:
[192.168.0.1]}]
172.16.0.2/32 10.200.0.2 65001 01:18:34
[{Origin: i} {Med: 0}]
192.168.0.0/24 10.200.0.2 65001 01:18:34
[{Origin: i} {Med: 0}]
192.168.1.0/24 192.168.10.3 65001 01:14:37
[{Origin: i} {Med: 0} {LocalPref: 100} {Originator: 10.203.0.6} {ClusterList:
[192.168.0.1]}]
However, I don't see any routes in the Linux forwarding table of the blue VRF:
[ashaikh@vsp-vpe-west ~]$ ip route show vrf blue unreachable default metric
4278198272
10.200.0.0/16 dev ens6 proto kernel scope link src 10.200.0.3
172.16.0.2 via 10.200.0.2 dev ens6 proto zebra metric 20
192.168.0.0/24 via 10.200.0.2 dev ens6 proto zebra metric 20
What I'd expect is something along these lines:
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
In other words, packets arriving from CE which are destined to one of these
prefixes will be encapsulated with two MPLS labels: 80 (inner label derived
from the VPNv4 route) and 19 (outer label derived from route for the next-hop
192.168.10.3 in the default table). The IP next-hop of 10.202.0.8 is also
derived from the route for the next-hop 192.168.10.3.
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.
thx
aman
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/gobgp-devel
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/gobgp-devel
