Multiple BGP daemons on a Linux host
From CT3
A large number of BGP routers are needed to simulate some peering, policy routing or route propagation scenarios. With a careful setup, you can run multiple Quagga BGP daemons on a single Linux host, significantly reducing the amount of equipment needed to perform the tests.
Contents |
Configuration guidelines
To run multiple Quagga BGP daemons on a single host you have to:
- Create a configuration file for each BGP daemon;
- Create an IP address for each daemon if you want all of them to connect to the same router.
- If needed, fix the IP routing on the Linux host.
- Allocate two unique TCP port numbers for each daemon; one is needed for the BGP protocol, the other for the VTY connections to the BGP daemon.
Since the daemons run BGP protocol on non-standard TCP port number, the router shall not try to establish active connections. Use the neighbor transport connection-mode passive router configuration command.
Sample lab setup
In this lab, we’ll emulate three external BGP peers on a single Linux box. The physical of the lab is shown in Figure 1 and the logical lab setup in Figure 2.
Create the BGP configurations
Create multiple configuration files in the Quagga system configuration directory (/usr/local/quagga if you’ve followed the installation instructions in this wiki). The following files are used in the sample lab:
| AS 65001 | AS 65002 | AS 65003 |
|---|---|---|
hostname AS65001
password test
!
router bgp 65001
bgp router-id 10.17.0.2
network 10.1.2.0/24
neighbor 10.17.0.1 remote-as 65000
!
line vty
no login
|
hostname AS65002 password test ! router bgp 65002 bgp router-id 10.17.0.3 network 10.1.3.0/24 neighbor 10.17.0.1 remote-as 65000 neighbor 10.17.0.1 update-source 10.17.0.3 ! line vty no login |
hostname AS65003 password test ! router bgp 65003 bgp router-id 10.17.0.4 network 10.1.4.0/24 neighbor 10.17.0.1 remote-as 65000 neighbor 10.17.0.1 update-source 10.17.0.4 ! line vty no login |
Create the IP addresses
The openvpn command is used to create persistent tap interfaces.
[root@fedora ~]# openvpn --mktun --dev tap1 [root@fedora ~]# openvpn --mktun --dev tap2
IP addresses with /32 subnet mask (host routes) are assigned to the tap interfaces. The addresses should be in the same IP subnet as the LAN interface:
[root@fedora ~]# ifconfig eth0 | egrep 'Link|Mask'
eth0 Link encap:Ethernet HWaddr 00:0F:FE:83:BC:A9
inet addr:10.17.0.2 Bcast: 10.17.0.255 Mask:255.255.255.0
inet6 addr: fe80::20f:feff:fe83:bca9/64 Scope:Link
[root@fedora ~]# ifconfig tap1 up 10.17.0.3 netmask 255.255.255.255
[root@fedora ~]# ifconfig tap2 up 10.17.0.4 netmask 255.255.255.255
Check the IP routing on the Linux box with the route command:
[root@fedora quagga]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.17.0.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 0 0 0 eth0 default gw 0.0.0.0 UG 0 0 0 eth0
Start the BGP daemons
The Quagga BGP daemons are started with command-line parameters that specify:
- The configuration file (-f)
- The local state file where the PID is stored (-i)
- The BGP non-standard TCP port number (-p)
- The VTY TCP port number (-P)
In the sample lab, the following commands are used to start the three daemons:
cd /usr/local/quagga # bgpd -f AS65001.conf -i AS65001.pid -p 20001 -P 2001 & bgpd -f AS65002.conf -i AS65002.pid -p 20002 -P 2002 & bgpd -f AS65003.conf -i AS65003.pid -p 20003 -P 2003 &
Configure the router
You can use very basic BGP configuration on the Cisco IOS router. It’s advisable to specify the passive connection mode to prevent the router from trying to establish the TCP session to well-known BGP port on the Linux host:
hostname R1 ! interface FastEthernet0/0 ip address 10.17.0.1 255.255.255.0 ! router bgp 65000 no synchronization bgp log-neighbor-changes network 10.1.1.0 mask 255.255.255.0 neighbor 10.17.0.2 remote-as 65001 neighbor 10.17.0.2 transport connection-mode passive neighbor 10.17.0.3 remote-as 65002 neighbor 10.17.0.3 transport connection-mode passive neighbor 10.17.0.4 remote-as 65003 neighbor 10.17.0.4 transport connection-mode passive no auto-summary ! ip route 10.1.1.0 255.255.255.0 Null0
After configuring the BGP routing process on R1, the BGP neighbors stay in Idle state (see below) and do not transition to Active due to the passive connection mode.
R1#show ip bgp summary | begin Neighbor Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.17.0.2 4 65001 0 0 0 0 0 never Idle 10.17.0.3 4 65002 0 0 0 0 0 never Idle 10.17.0.4 4 65003 0 0 0 0 0 never Idle
However, once the Quagga BGP daemons initiate TCP sessions to the router, the BGP adjacencies are established and the BGP routes exchanged:
*Oct 18 23:14:47.359: %BGP-5-ADJCHANGE: neighbor 10.17.0.4 Up
*Oct 18 23:14:47.403: %BGP-5-ADJCHANGE: neighbor 10.17.0.3 Up
*Oct 18 23:14:48.359: %BGP-5-ADJCHANGE: neighbor 10.17.0.2 Up
R1#show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.17.0.2 4 65001 5 8 5 0 0 00:01:27 1
10.17.0.3 4 65002 5 8 5 0 0 00:01:28 1
10.17.0.4 4 65003 5 8 5 0 0 00:01:28 1
R1#show ip bgp
BGP table version is 5, local router ID is 10.17.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 0.0.0.0 0 32768 i
*> 10.1.2.0/24 10.17.0.2 0 0 65001 i
*> 10.1.3.0/24 10.17.0.3 0 0 65002 i
*> 10.1.4.0/24 10.17.0.4 0 0 65003 i


BlogMarks
del.icio.us
digg
Facebook
LinkedIn
Newsvine
reddit
Slashdot