BGP in virtual routers¶
BGP configuration and monitoring in VRF¶
Usually, BGP router is configured in VR main. To handle virtual routers, a separate VRF can be specified. The routes learnt and configured will be stored in the corresponding forwarding tables. It is possible to create multiple BGP instances on the same machine.
Create a BGP instance on a VRF named
customer1, by using following command:
vrf customer1
routing bgp
as 54
..
..
Then you can continue the configuration as usual. The BGP peering and the redistribution will happen on the whole VRF. All configured interfaces with addresses, and routing information on that VRF will be used.
To get routing information about BGP in that VR instance, you can use following command, that will dump all the instances configured.
vrouter> show bgp vrfs
Type Id routerId #PeersVfg #PeersEstb Name L3-VNI Rmac
DFLT 0 192.168.0.162 2 1 Default 0 00:00:00:00:00:00
VRF 2 0.0.0.0 0 0 customer1 0 00:00:00:00:00:00
VRF 3 1.1.1.1 0 0 customer2 0 00:00:00:00:00:00
To get more information on a specific VRF, you can use following command, and the VRF name to get routing information:
vrouter> show bgp vrf customer1 ipv4 unicast
BGP table version is 2, local router ID is 1.1.1.1, vrf id 2
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 3.3.3.0/24 0.0.0.0 0 32768 i
*> 4.4.4.0/24 0.0.0.0 0 32768 i
Displayed 2 routes and 2 total paths
BGP use case for VRF¶
A common use case is to provide a per customer BGP peering. This use case can happen, when several customers share physical resources of a machine, but are isolated by means of either physical interfaces or VLAN interfaces. The following configuration gives an overview on how to create multiple BGP instances tighted with VLAN interfaces.
As you can see on below example, 2 instances of BGP are created, each one run over VLAN interface with its own peer. The same autonomous system can be used for all the instances. The BGP contexts share the same system process but will not share the same forwarding information.
vrf customer1
routing bgp
as 65555
router-id 192.168.1.1
neighbor 192.168.1.2 remote-as 65555
..
..
interface vlan vlan10
vlan-id 10
link-interface eth0_0
ipv4 address 192.168.1.1/24
..
..
..
vrf customer2
routing bgp
as 65555
router-id 192.168.2.1
neighbor 192.168.2.2 remote-as 65555
..
..
interface vlan vlan20
vlan-id 20
link-interface eth0_0
ipv4 address 192.168.2.0/24
..
..
Note
With the above example, it could have been possible to use the same IP mapping for both routing entities. An other benefit of having separate entities is that IP mapping can overlap.
BGP use case for cross-VRF routes¶
An other common use case is to install cross-VRF routes between 2 BGP instances.
A proposal consists in using a mesh of BGP peerings via veth links. Below example
illustrates what can be done to install cross VRF routes routes between admin vrf
and service vrf.
vrf admin
interface physical eth0
port pci-b0s5
ipv4 address 192.168.2.1/24
.. ..
interface veth service1
link-interface admin
link-vrf service1
.. ..
interface veth service2
link-interface admin
link-vrf service2
.. ..
interface loopback localip
ipv4 address 169.254.0.100/32
.. ..
routing static ipv4-route 169.254.0.101/32 next-hop service1
routing static ipv4-route 169.254.0.102/32 next-hop service2
routing bgp
as 11
ebgp-connected-route-check false
router-id 192.168.2.1
address-family ipv4-unicast
redistribute connected route-map nolocal
.. ..
neighbor 192.168.2.2
remote-as 12
address-family ipv4-unicast as-outbound-update
action remove as-type all
.. .. .. ..
neighbor-group local update-source localip
neighbor 169.254.0.101
remote-as 64601
local-as as-number 64600 no-prepend true replace-as true
neighbor-group local
..
neighbor 169.254.0.102
remote-as 64602
local-as as-number 64600 no-prepend true replace-as true
neighbor-group local
..
..
..
..
vrf service1
interface physical eth1
port pci-b0s6
ipv4 address 10.1.2.1/24
.. ..
interface veth admin
link-interface service1
link-vrf admin
.. ..
interface loopback localip
ipv4 address 169.254.0.101/32
.. ..
routing static ipv4-route 169.254.0.100/32 next-hop admin
routing bgp
as 11
ebgp-connected-route-check false
router-id 10.1.2.1
address-family ipv4-unicast
redistribute connected route-map nolocal
.. ..
neighbor 10.1.2.2
remote-as 13
address-family ipv4-unicast as-outbound-update
action remove as-type all
.. .. .. ..
neighbor-group local update-source localip
neighbor 169.254.0.100
remote-as 64600
local-as as-number 64601 no-prepend true replace-as true
neighbor-group local
..
..
..
..
vrf service2
interface physical eth2
port pci-b0s4
ipv4 address 10.2.2.1/24
.. ..
interface veth admin
link-interface service2
link-vrf admin
.. ..
interface loopback localip
ipv4 address 169.254.0.102/32
.. ..
routing static ipv4-route 169.254.0.100/32 next-hop admin
routing bgp
as 11
ebgp-connected-route-check false
router-id 10.2.2.1
address-family ipv4-unicast
redistribute connected route-map nolocal
.. ..
neighbor 10.2.2.2
remote-as 14
address-family ipv4-unicast as-outbound-update
action remove as-type all
.. .. .. ..
neighbor-group local update-source localip
neighbor 169.254.0.100
remote-as 64600
local-as as-number 64602 no-prepend true replace-as true
neighbor-group local
..
..
..
..
routing ipv4-access-list local seq 1 permit 169.254.0.0/24
routing route-map nolocal
seq 1
policy deny
match ip address access-list local
..
seq 2
policy permit
..
..
..
In addition to establish 2 eBGP sessions with external devices, an internal BGP
peering is established between 3 VRs. Below dump gives an overview of the BGP
sessions from VRF admin perspective.
rt1> show bgp vrf admin summary
IPv4 Unicast Summary:
BGP router identifier 192.168.2.1, local AS number 11 vrf-id 2
BGP table version 3
RIB entries 5, using 920 bytes of memory
Peers 3, using 61 KiB of memory
Peer groups 1, using 64 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
169.254.0.101 4 64601 10 18 0 0 0 00:04:30 1 3 N/A
169.254.0.102 4 64602 10 18 0 0 0 00:04:30 1 3 N/A
192.168.2.2 4 12 23 23 0 0 0 00:18:03 0 3 N/A
Note that the above example illustrates peering with eBGP connections with external
devices, but also internally with peers on other VRs. Because /32 bit routes have
been used to connect to remote veth peers, routes learnt via those peers could not be
installed locally because BGP checks against recursivity for eBGP connections. This
option has been relaxed, by using ebgp-connected-route-check command.
To distinguish the two kinds of peerings, local-as option has been used to replace the
original AS number with a private AS number to show to peers from veth links. A
side effect of this usage is that the AS-PATH list is made up of public and private ASes.
To remove private AS and keep only public AS, the following command is used by BGP
before sending advertisements to external devices: as-outbound-update action remove all.
Below dump gives an extract of RIB of the configured device, and a remote device connected to VRF admin. As you can see, on remote BGP, private ASes have been removed from AS-PATH list.
rt1> show bgp vrf admin ipv4
BGP table version is 3, local router ID is 192.168.2.1, vrf id 2
Default local pref 100, local AS 11
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.1.2.0/24 169.254.0.101 0 0 64601 ?
*> 10.2.2.0/24 169.254.0.102 0 0 64602 ?
*> 20.1.1.0/24 169.254.0.101 0 64601 13 i
*> 192.168.2.0/24 0.0.0.0 0 32768 ?
Displayed 3 routes and 3 total paths
rt2> show bgp ipv4
BGP table version is 3, local router ID is 192.168.2.2, vrf id 0
Default local pref 100, local AS 12
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.1.2.0/24 192.168.2.1 0 11 ?
*> 10.2.2.0/24 192.168.2.1 0 11 ?
*> 20.1.1.0/24 192.168.2.1 0 11 13 i
*> 192.168.2.0/24 192.168.2.1 0 0 11 ?
An other method to get rid of private ASes would consist in filtering the AS
in incoming as-path list on the veth peerings.
vrf admin
routing bgp
neighbor 192.168.2.2 address-family ipv4-unicast
del as-outbound-update
.. .. ..
neighbor-group local
address-family
ipv4-unicast
route-map in route-map-name alteraspath
..
..
.. .. .. ..
vrf service1
routing bgp
neighbor 10.1.2.2 address-family ipv4-unicast
del as-outbound-update
.. .. ..
neighbor-group local
address-family
ipv4-unicast
route-map in route-map-name alteraspath
..
..
.. .. .. ..
vrf service2
routing bgp
neighbor 10.2.2.2 address-family ipv4-unicast
del as-outbound-update
.. .. ..
neighbor-group local
address-family
ipv4-unicast
route-map in route-map-name alteraspath
..
..
.. .. .. ..
routing route-map alteraspath
seq 100
policy permit
match
peer 169.254.0.100
..
set
as-path
exclude 64600
..
..
..
seq 101
policy permit
match
peer 169.254.0.101
..
set
as-path
exclude 64601
..
..
..
seq 102
policy permit
match
peer 169.254.0.102
..
set
as-path
exclude 64602
..
..
..
Using a full iBGP network is also an other solution to get rid of AS-PATH list handling.
In that case, nexthop-self attribute may be used under each peer address family, because
the mesh will be incomplete. For instance, the peers behind VRF admin would not be
connected to peer connected behind VRF service1.
Finally, as veth is an ethernet medium like many external links, any other routing protocol
can be used to transmit routing information to remote endpoints.