Errors with VRF commands in bgp.conf

[amanshaikh75]

I am using the HEAD of the Master branch.

[ashaikh@vsp-vpe-west:~]$ bgpd -v
bgpd version 4.1-dev
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
         '--prefix=/usr' '--localstatedir=/var/run/frr' '--sbindir=/usr/sbin' '--sysconfdir=/etc/frr' '--enable-multipath=64' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' '--enable-systemd=yes' '--enable-ldpd' '--enable-mpls'

I am getting an error with this config file for bgp:

router bgp 65002
  bgp disable-ebgp-connected-route-check
  bgp router-id 192.168.0.1
!
! VRF red
router bgp 65002 vrf red
  rd vpn export 100:2
  ! Session with vce-west-red
  neighbor 10.201.0.3 remote-as 65003
  neighbor 10.201.0.3 next-hop-self
  neighbor 10.201.0.3 ebgp-multihop
  neighbor 10.201.0.3 update-source 192.168.0.1
[ashaikh@vsp-vpe-west:~]$ sudo bgpd -C -f etc/bgp.conf
2018/03/27 17:35:15 errors: BGP: ERROR: No such command on config line 7:   rd vpn export 100:2

I am getting similar error for these statements in the config file as well:

  rt vpn both 100:2
  import vpn
  export vpn

[riw777]

This is incorrect syntax -- these commands need to be inside an address family block.

[rwestphal]

Here's a very simple L3VPN topology using FRR: https://gist.github.com/rwestphal/45ca016a0d54f52f4eb869a99719b90e

Hope it helps.

[amanshaikh75]

Immensely useful Renato. Thanks a lot!

Using your PE BGP config as a reference, I managed to successfully write config file for a PE in my set-up.
However, I ran into two problems, but before going into details, here's the relevant config file of the PE:

[ashaikh@vsp-vpe-west:~]$ cat etc/bgp.conf
log file /var/log/frr/bgpd.log
router bgp 65002
  bgp router-id 192.168.0.1
  !
  ! Peering session with core RR.
  neighbor 192.168.0.2 remote-as 65002
  neighbor 192.168.0.2 next-hop-self
  neighbor 192.168.0.2 update-source lo:1
  address-family ipv4 vpn
   neighbor 192.168.0.2 activate
!
! VRF red
router bgp 65002 vrf red
  bgp disable-ebgp-connected-route-check
  bgp router-id 192.168.0.1
  !
  ! Session with vce-west-red
  neighbor 10.201.0.3 remote-as 65003
  neighbor 10.201.0.3 next-hop-self
  neighbor 10.201.0.3 ebgp-multihop
  neighbor 10.201.0.3 update-source lo:1
  !
  ! IPv4 routes
  address-family ipv4 unicast
    import vpn
    export vpn
    rt vpn both 100:2
    rd vpn export 100:2
    neighbor 10.201.0.3 activate

The PE has one VRF (red) and one session with a CE (running FRR BGP daemon) in this VRF. The session with CE was established successfully. The PE received two routes over this session.

vsp-vpe-west# show bgp vrf red ipv4
BGP table version is 4, local router ID is 192.168.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
              i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.2/32    10.201.0.3               0             0 65003 i
*> 192.168.100.0    10.201.0.3               0             0 65003 i

BGP daemon on the PE exported these routes to the default table as expected.

vsp-vpe-west# show bgp ipv4 vpn
BGP table version is 2, local router ID is 192.168.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
              i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:2
*> 172.16.0.2/32    0.0.0.0         0             0 65003 i    UN=0.0.0.0 EC{100:2} label=12288 type=bgp, subtype=5
*> 192.168.100.0    0.0.0.0         0             0 65003 i    UN=0.0.0.0 EC{100:2} label=12288 type=bgp, subtype=5

Both routes were assigned a label of 12,288. I believe BGP daemon gets this from the label manager running within Zebra daemon.

So far so good!

Now to the problems I am observing:

Problem 1: Given the label assignment above, I expected to see an MPLS route in Zebra for label 12,288 which I am afraid I didn't.

vsp-vpe-west# show mpls table
 Inbound                            Outbound
   Label     Type          Nexthop     Label
--------  -------  ---------------  --------
      16      LDP       10.202.0.8  implicit-null
      17      LDP       10.202.0.8        17

The route I expected to see in the MPLS table above should look like this:
12288 BGP red

Without this route, incoming (MPLS) packets (with label=12288) from the core for red VRF would be dropped by this PE.

Problem 2: The BGP daemon on the PE sent the VPNv4 routes to the RR (session with 192.168.0.2). However, it set the label to 0 instead of 12288.

[ashaikh@vsp-core-rtr ~]$ gobgp global rib -a vpnv4
   Network                Labels     Next Hop             AS_PATH              Age        Attrs
*> 100:2:172.16.0.2/32    [0]        192.168.0.1          65003                00:06:26   [{Origin: i} {Med: 0} {LocalPref: 100} {Extcomms: [100:2]}]
*> 100:2:192.168.100.0/24 [0]        192.168.0.1          65003                00:06:26   [{Origin: i} {Med: 0} {LocalPref: 100} {Extcomms: [100:2]}]

I admit that I was running gobgpd daemon on the route-reflector, and that could be part of the problem. However, I've seen gobgpd correctly receive VPNv4 routes (with right labels) from PEs running gobgpd daemon in the past. This makes me think that the problem is with the FRR BGP side.

Let me know what you think.

[amanshaikh75]

When I explicitly configured label in the config file, the label is passed in the VPNv4 routes, and MPLS route is installed in the global forwarding table. This gives me a work-around. However, it would be nice if BGP daemon can use a VRF-label that's assigned dynamically by the label-manager in Zebra. This would prevent label collisions when other routing protocols that use labels (e.g., LDP) are also running.

[rwestphal]

Both routes were assigned a label of 12,288. I believe BGP daemon gets this from the label manager running within Zebra daemon.

That was actually a bug in bgpd, 12288 is how little-endian processors store the number 3 (the implicit-null label) in a 4-bytes integer. Paul already fixed this bug, along with several others, so I suggest you to pull the latest changes from master and repeat your tests again.

This gives me a work-around. However, it would be nice if BGP daemon can use a VRF-label that's assigned dynamically by the label-manager in Zebra.

Now it's possible to do that using the label vpn export auto command, which was merged into master a couple of weeks ago.

[amanshaikh75]

I updated my repository, and I can see VRFs are getting their labels automatically. Thanks.