Supporting BGP/MPLS VPNs (RFC 4364)

[amanshaikh75]

GoBGP supports many ingredients required for supporting BGP/MPLS VPNs (as specified in RFC 4364 - https://tools.ietf.org/search/rfc4364) such VPNv(4|6) NLRI, route targets, route-distinguishers and VRFs.
These ingredients are enough to use GoBGP as a route-reflector (RR) for a VPN service.

However, several features are missing in GoBGP which make it impossibe to use GoBGP as a Provider Edge (PE) router in a VPN service:

• When IP routes are imported from VRFs into the default RIB as VPN routes, the MPLS label assigned is zero. This problem is addressed by zclinet: Enable to request MPLS label range to FRRouting #1587 which uses Zebra's label manager to get a range of MPLS labels and then assigns one label to every VRF.

• For each VRF label, GoBGP needs to install an MPLS route into the default forwarding table which pops the label from incoming packets and re-directs them to the VRF forwarding table for further processing. In Linux kernel, such route takes the form of "<vrf_label> dev <vrf_name>". Unfortunately, the required support from FRR/Zebra does not exist in the its current stable release (https://github.com/FRRouting/frr/releases/tag/frr-3.0.3). The good news is that FRR has now added support for adding such routes through its Zebra API -- see Supporting MPLS label popping followed by sending packet to VRF device FRRouting/frr#1759 for more information. The flip side is that this requires modifying GoBGP to support Zebra API (ZAPI) version 5 (in addition to currently supported versions of 3 and 4). I have added fix for all problems related to installation of routes in VRF and default tables for L3VPNs to work. See pull request Zapi version 5 #1766.

• When VPN routes are received from VPN route-reflector or other PEs, GoBGP correctly imports them into VRFs based on import targets. However, it does not add appropriate route in the VRF's forwarding table so that packets coming in from the CE are encapsulated with two MPLS labels -- inner one for the VRF on the egress PE and the outer one for loopback of the egress PE -- and sent to towards the egress PE. More importantly, handling of VRFs in GoBGP seems flawed. See Dealing with VRFs #1648 for details.

• Finally, I have identified a bug in GoBGP where VPN routes received from route-reflector or other PEs are installed in default forwarding table if no VRF exists that can import these routes. While this is not a show-stopper for correct functioning, it is not correct behavior and can unnecessarily fill up the default table. I've opened an issue about this: VPNv4 routes are added to the default forwarding table when no VRF exists #1609. See https://github.com/amanshaikh75/gobgp/blob/disallow_vpn_routes_in_default_fwd_table/server/zclient.go#L508 for a possible fix.

[brotherdust]

@amanshaikh75 were your changes ever accepted (specifically ZAPI v5)? I cannot seem to verify it was based on the commit history.

[amanshaikh75]

@brotherdust - no, my changes haven't been accepted into master branch of GoBGP.

aman

[brotherdust]

@amanshaikh75, any particular reason why? They just haven't gotten around to it? It would be quite useful!

[amanshaikh75]

@brotherdust - GoBGP didn't seem very interested in supporting ZAPI 5. I fully agree it would be very useful. The only downside is the complexity arising from supporting various ZAPI versions.

[brotherdust]

@amanshaikh75 I'm not from GoBGP, but may I suggest splitting this issue into its constituent parts so that they may be handled individually? It might increase your chances for success. I'll try to bring it up in the slack channel.

[brotherdust]

@amanshaikh75 also, I don't see a pull request for this into osrg/gobgp. Have you submitted it? Maybe I'm missing it.

[amanshaikh75]

@brotherdust I haven't created a pull request for it since I didn't see any interest from GoBGP team. If you want, I can create a pull request, and see what happens.

As for splitting the issue, this is already done. I mention the corresponding issue in each paragraph. In fact, the reason behind creating this issue was to consolidate all VPN-related issues at one place at the request of @iwaseyusuke .

[brotherdust]

Honestly? Yeah. I'd give it a shot. The worst they can say is no. I'll voice some support for it when it comes through.

Re: splitting the issue: makes sense. I'm not sure what their deal is.