BGP++ DOCUMENTATION
1. Introduction
This goal of this tutorial is to get you started with BGP++. It's assumed that you are familiar with ns-2. The overview section makes an introduction in BGP++, explaining the fundamentals of creating BGP simulations. Then, the examples elaborate on some common BGP scenarios/examples that are based on case studies found in Cisco BGP page.2. Overview
1.1 Creating the topology
The first step to run a BGP simulation is to create the desired topology.
Details on how to do this can be found on ns-2 Manual. The following tcl
code creates a simple topology of two nodes connected trough a 1Mb link.
set ns [ new Simulator ]Before creating actual BGP instances, the BGP registry has to be initiated. The BGP registry is a database that is used by BGP instances to map IP addresses to BGP instances. Only one BGP registry per simulation is required. The following command creates a BGP registry:
set n1 [$ns node]
set n2 [$ns node]
$ns duplex-link $n1 $n2 1Mb DropTail
#initiate bgp registrySuppose, we want to initialize two BGP instances on the two nodes we created above. The following piece of code initializes two BGP instances on nodes n1 and n2. The command “$BGP1 register $r” registers the bgp instance. The command “$BGP1 finish-time 2000” informs the routers on the finish time of the simulation. The command “$BGP1 config-file /home/BGP/doc/example1/bgpd1.conf” associates a configuration file to router BGP1. Finally, the command "$BGP1 cpu-load-model uniform a b", sets the workload model to uniform. The way the workload is modeled is that each time a simulated bgpd returns control to the simulator it picks a busy-period value. This value represents the finite execution time. During the busy-period, the bgpd does not respond to any invocations, which could be the result of packet arrivals or timer expirations, instead of this, all invocations are buffered and executed in a FIFO basis as soon as the busy-period expires. BGP++ has two workload models that differ only in how they choose the busy-period. In the uniform workload model, the busy-period is a uniform random variable within a user specified range. In the time-sample model, the busy-period is calculated as the product of the CPU clock frequency and the execution cycles count. The execution cycles count is the CPU cycles measured from the invocation of the bgpd to just before control is returned to the simulator. The package perfctr-2.5.1 provides the required performance monitoring utilities. By default a BGP router uses no workload model. The syntax to enable the time-sample model is: "$BGP1 cpu-load-model time-sample".
set r [new BgpRegistry]
set BGP1 [new Application/Route/Bgp]
$BGP2 register $r ; #register the bgp instance
$BGP1 finish-time 2000 ; #let the instance know when the simulation ends
$BGP1 config-file /home/BGP/doc/example1/bgpd1.conf; #associate a configuration file
$BGP1 attach-node $n1; #attach to node 1
$BGP1 cpu-load-model uniform 0.0001 0.00001; #set a workload model
set BGP2 [new Application/Route/Bgp]
$BGP2 register $r
$BGP2 finish-time 2000
$BGP2 config-file /home/BGP/doc/example1/bgpd2.conf
$BGP2 attach-node $n2
$BGP2 cpu-load-model uniform
1.2 Configuring BGP routers
So far we created a simple topology of two nodes and we attached one BGP instance to each node. Also, we associated the configurations files bgpd1.conf and bgpd2.conf to the two instances. The configuration files, is where most of BGP configuration takes place. To configure a BGP instance one has to use the configuration syntax used by Zebra bgpd.Suppose we want to configure the two BGP instances, initialized earlier, to belong to AS 1 and AS 2 that peer.
First, IP addresses and AS numbers have to be assigned to the routers (We randomly choose IP addresses and AS numbers).
bgpd1.conf:Then, we configure each instance's neighbors.
router bgp 1
bgp router-id 192.38.14.1
bgpd2.conf:
router bgp 2
bgp router-id 192.38.14.2
bgpd1.conf:The previous commands, instruct the two BGP instances to establish a BGP session and exchange the routes they know. So far, no prefixes/routes have been assigned to the peers. To do so, we use the "network A.B.C.D mask A.B.C.D" command:
neighbor 192.38.14.2 remote-as 2
bgpd2.conf:
neighbor 192.38.14.1 remote-as 1
bgpd1.conf:We note that since there is no IGP protocol implemented in ns-2, we can only statically configure the networks that are originated (no redistribution originated -IGP to BGP- routes exist).
network 190.0.0.0 mask 255.0.0.0
network 189.0.0.0 mask 255.0.0.0
bgpd2.conf:
network 193.0.0.0 mask 255.0.0.0
network 194.0.0.0 mask 255.0.0.0
The following commands enable logging.
bgpd1.conf,bgpd2.conf:And assign log files
debug bgp
debug bgp fsm
debug bgp keepalives
debug bgp filters
debug bgp events
debug bgp updates
bgpd1.conf:This subsection has described how basic configuration of BGP instances is done. If we run the simulation, ns-2 will instanciate the two BGP routers. Then, each router will parse its configuration file and the two BGP instances will establish a tcp session and will exchange the routes they know; then, they will maintain the session by exchanging KEEPALIVES. You can find the configuration files here (they also ship with BGP++ distribution): 2peer.tcl, bgpd1.conf, bgpd2.conf.
log file bgpd1.log
bgpd2.conf:
log file bgpd2.log
1. 3 Run time commands
Run-time commands are commands that are executed at some point during the simulation ( the configuration commands we saw above are executed immediately after the beginning of the simulation when the configuration file is parsed). The run time commands are used to replace the functionality available in Zebra bgpd through the telnet interface. There are two types of run time commands, commands that change the configuration of the BGP instances and commands that ask the simulated BGP routers for some kind of information. Both types of commands are called from the tcl script using the following syntax:$ns at TIME "$BGP1 command \"COMMAND TO BE EXECUTED \""The following examples illustrate the two types of run time commands.
Changing configuration at run time
This command makes BGP instance BGP1 reset all connections 20 seconds after the beginning of the simulation.
$ns at 20 "$BGP1 command \"clear ip bgp * \""This command completely removes neighbor 192.38.0.1 from BGP2's list of neighbors 150 sec after the beginning of the simulation.
$ns at 150 "$BGP2 command \"no neighbor 192.38.0.1\""Showing information at run time
This commands prints BGP1's routing table at the 21st second of the simulation. The routing table is printed in the log file, specified by the "log file filename" command.
$ns at 21 "$BGP1 command \"show ip bgp \""The following command prints the specified ip prefix list.
$ns at 10 "$BGP2 command \"show ip prefix-list PR_LIST\""
2. Examples
2.1 BGP Confederations
BGP Confederations are used to reduce the number of necessary iBGP connection. Without BGP Confederations or Route Reflectors, a mesh topology is required for iBGP routers. Obviously, a mesh topology does not scale well; to overcome this problem, we divide routers into multiple smaller ASs. The smaller ASs constitute one confederation.In the rest of this sub-section, we show how to configure a simulated BGP confederation.
Suppose we have AS500 consisting of nine BGP speakers (BGP1-9) and that our AS connects to two eBGP peers (BGP10-11). To avoid the full mesh requirement for AS 500, we divide it in sub-ASs: AS50 (BGP1-3), AS60 (BGP4-6), and AS70 (BGP7-9).
The commands:
bgp confederation identifier autonomous-systemare used to assign a confederation id, and to list the peers of each sub-AS.
bgp confederation peers autonomous-system [autonomous-system]
The file confederations.tcl specifies the interconnection of the 11 routers. The files: bgpd1.conf, bgpd2.conf, bgpd3.conf, bgpd4.conf, bgpd5.conf, bgpd6.conf,bgpd7.conf, bgpd8.conf, bgpd9.conf, bgpd10.conf and bgpd11.conf specify the configuration of each simulated router. All files referenced in the examples section are distributed with BGP++.
Each router is configured to advertise two /24 prefixes. Also, no policies are applied, meaning that the routers won't filter any inbound/outbound advertisements.
The command:
$ns at 99 "$BGP4 command \"show ip bgp\""
shows BGP4's routing table 99 seconds after the beginning of the simulation.The output of the command is recorded at router's 4 log file:
To examine the format of the packets exchanged between the BGP instances, packet dumping is enabled:BGP table version is 0, local router ID is 192.38.0.9
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> i10.0.1.0/24 192.38.0.1 100 0 (60 50) i
*> i10.0.2.0/24 192.38.0.2 100 0 (60 50) i
*> i10.0.3.0/24 192.38.0.3 100 0 (60 50) i
*> i10.0.4.0/24 192.38.0.4 100 0 (60) i
*> i10.0.5.0/24 192.38.0.5 100 0 (60) i
*> i10.0.6.0/24 192.38.0.6 100 0 i
*> i10.0.7.0/24 192.38.0.7 100 0 i
*> i10.0.8.0/24 192.38.0.8 100 0 i
*> 10.0.9.0/24 0.0.0.0 32768 i
*> i10.0.10.0/24 192.38.0.10 100 0 (60 50) 100 i
*> i10.0.11.0/24 192.38.0.11 100 0 (60) 600 i
*> i11.0.1.0/24 192.38.0.1 100 0 (60 50) i
*> i11.0.2.0/24 192.38.0.2 100 0 (60 50) i
*> i11.0.3.0/24 192.38.0.3 100 0 (60 50) i
*> i11.0.4.0/24 192.38.0.4 100 0 (60) i
*> i11.0.5.0/24 192.38.0.5 100 0 ( 60) i
*> i11.0.6.0/24 192.38.0.6 100 0 i
*> i11.0.7.0/24 192.38.0.7 100 0 i
*> i11.0.8.0/24 192.38.0.8 100 0 i
*> 11.0.9.0/24 0.0.0.0 32768 i
*> i11.0.10.0/24 192.38.0.10 100 0 (60 50) 100 i
*> i11.0.11.0/24 192.38.0.11 100 0 (60) 600 i
Total number of prefixes 22
dump bgp updates pathThe packets are dumped in Zebra-MRT format. There are several tools that can read Zebra-MRT format. Using PyRT (Python Routing Toolkit) we show a snapshot of the updates exchanged.
[ Fri Feb 21 11:19:30 2003 ]
MRT packet: len: 72, type: PROTOCOL_BGP4MP, subtype: MESSAGE
AS(src): 60, AS(dst): 50
ifc idx: 0, AFI: IP
IP(src): 192.38.0.4, IP(dst): 192.38.0.1
Update (len=56): unfeasible_len=0 path_attr_len=29
UNFEASIBLE ROUTES:
PATH ATTRIBUTES:
ORIGIN: IGP [ transitive ]
AS_PATH: (CONFED_SET){ 60, }(SEQUENCE)[ <- 600 ] [ transitive ]
NEXT_HOP: 192.38.0.11 [ transitive ]
LOC_PREF: 100L [ transitive ]
FEASIBLE ROUTES:
1: 11.0.11.0/24
This is an update sent from router 4 to router 1. The update is for prefix 11.0.11.0/24 that originates in AS 600, router 11. We note that router 4 did not change the next-hop attribute as it is required for iBGP. Also, the CONFED_SET segment type is used (defined in RFC 1965) for the AS60 segment of the AS path.
The configuration files are distributed with BGP++.
2.2 Route Reflector
BGP routers do not redistribute prefixes learnt by iBGP to other iBGP peer. However all prefixes used by a BGP router have to be communicated to all other iBGP routers. To accommodate those two requirements, RFC 1771 requires a mesh topology for iBGP routers. As we have seen in the previous sub-section, BGP Confederations relax this requirement. Another approach is to allow some routers, Route Reflectors (RR), to advertise (redistribute) iBGP learnt routes to other iBGP routers. The advantage of this approach is that the routers that peer to a route reflector do not need to peer to any other router. Thus, a mesh topology is not necessary. However, the AS has to be partitioned into clusters, and each cluster has to be assigned at least one route reflector. The route reflectors still have to be interconnected in a mesh topology.
AS 100 has two clusters; the first consists of routers: 2,3,4,5, where 2 and 3 are configured as route reflectors. The second cluster is composed of routers 6 (Route Reflector), 7 and 8. Router 1 is not part of any of the two clusters. Special configuration is necessary only for the RR's. For each of the three RR's we configure its clients. Also, it's necessary to specify a cluster-id for routers 2 and 3, which are RR's for the same cluster. Finally, each router is statically configured with a /24 prefix (route-reflector.tcl).
The command:
neighbor A.B.C.D route-reflector-clientspecifies that the configured router acts as a Route Reflector for neighbor A.B.C.D.
The command:
bgp cluster-id numis necessary in the configuration of a RR only when two or more RR's are defined for the same cluster. All RR's in the same cluster should be configured with the same cluster id. The RR attaches its cluster-id in the cluster list field of the updates that are sent outside the cluster to prevent iBGP routing loops in the same manner as the AS path is used in eBGP.
Every router is configured with /24 prefix; since no policies are applied we should expect that after the network converges each router should have 12 /24 entries in its routing table. If we examine the log files created by the simulation, we see that this is true for all routers.
2.3 Route Flap Dampening
Route Flap Dampening is a mechanism used to decrease instability in the Internet. It constrains misbehaved routes and prevents oscillations from propagating all over the Internet. Route Flap Dampening assigns a penalty to a route, each time the route flaps. If the route flaps often, then the penalty accumulates, when a pre-specified limit is reached the route is suppressed. The penalty assigned to a route decreases exponentially with time. The rate at which the penalty decreases is controlled by a configurable half-time parameter. If the penalty decreases bellow the reuse threshold, then the route is unsuppressed.
Route Flap Dampening is turned off by default. To turn it on (or off), one needs to use one of the commands:
bgp dampening
Enables route-flap dampening with default parameters
Default Parameters:
Half-lifetime for the penalty :15 min
Value to start reusing a route :750
Value to start suppressing a route :2000
Maximum duration to suppress a stable route :4*15 min
bgp dampening <1-45> <1-20000> <1-20000> <1-255>
Enables route-flap dampening
1st argument: Half-lifetime for the penalty (min)
2nd argument: Value to start reusing a route
3rd argument: Value to start suppressing a route
4th argument: Maximum duration to suppress a stable route (min)
bgp dampening <1-45>
Enables route-flap dampening
1st argument: Half-life time for the penalty
no bgp dampening
Disables route-flap dampening
no bgp dampening <145> <1-20000> <1-20000> <1-255>
Disables route-flap dampening
In this scenario we assume that we have three routers 1,2 and 3, in the AS1, AS2 and AS3 respectively, connected in a bus topology. Router 3 is statically configured with a /24 prefix, while router 2 has route flap dampening enabled. We make the only prefix configured flap, by calling repeatedly, at run-time, the "network A.B.C.D" and "no network A.B.C.D" commands for router 3. In particular, we flap 10.0.3.0 /24 prefix 3 times ( one advertisement/withdrawal every 50 sec ). Using the "show ip bgp 10.0.3.0" command we get information on how the penalty assigned on the route changes. After each flap a 1000 penalty is assigned by router 2; thus, after three flaps the 2000 limit is reached (2 flaps --2000 penalty -- are not enough to suppress the route since the penalty decays with time to a total less than the 2000 threshold). As soon as the prefix is supressed, any further oscillations do not propagate to router 1. If we re-announce the /24 prefix from router 3 after substantial time, e.g. 4000 seconds, we observe that the announcement is propagated to router 1. The prefix is not suppressed any more, since the penalty has decreased bellow the reuse threshold (flap-dampening.tcl).
2.4 Applying Policies
There are several ways one can apply policies with BGP++. For those familiar with BGP policies, the following can be used in the same manner as they are used on regular routers:route mapsThe following examples illustrate how route maps and the different types of lists are used.
access lists
community lists
as-path lists
prefix lists
Example 1
Assume routers BGP1 (AS1) and BGP2 (AS2); BGP2 advertises three networks: 10.0.1.0/24, 10.0.2.0/24 and 10.0.3.0/24. Router BGP1 does not accept advertisements for network 10.0.1.0/24 by AS2. To accomplish this, a route map is applied on the inbound updates received by BGP1. The configuration file for the first router is the following:
router bgp 1Only the routes that match the access-list 1 are permitted.
bgp router-id 192.38.0.1
neighbor 192.38.0.2 remote-as 2
neighbor 192.38.0.2 route-map MY_RM in
access-list 1 deny 10.0.1.0/24
access-list 1 permit any
route-map MY_RM permit 10
match ip address 1
Lets assume that at some point after the beginning of the simulation we want to change the applied policies and accept all announcements from router 2.
We can do so from the tcl configuration file using the commands:
#change access-listThe log file generated by the simulation shows that after the reset of the connection BGP1 accepts all advertisements made by BGP2. The files can be found here: ex1.tcl, bgpd1.conf, bgpd2.conf.
$ns at 50 "$BGP1 command \"no access-list MY_RM deny 10.0.1.0/24\""
#reset connection
$ns at 51 "$BGP1 command \"clear ip bgp 2\""
Example 2
Another method to filter incoming updates is to use prefix lists. Prefix lists, in contrast to access lists, associate a prefix length range to each specified prefix and mask. Updates that fall in the specified range are permitted or denied depending on the policy.
Suppose that routes BGP1 advertises the following prefixes:
192.32.10.0/24
10.10.10.0/24
10.10.0.0/16
BGP1:The "show ip bgp" command confirms that the prefix list is working as expected:
router bgp 1
network 192.32.10.0
network 10.10.10.0 mask 255.255.255.0
network 10.10.0.0 mask 255.255.224.0
neighbor 192.38.0.2 remote-as 2
BGP2:
router bgp 2
neighbor 192.38.0.1 remote-as 1
neighbor 192.38.0.2 prefix-list PR_LIST in
ip prefix-list PR_LIST seq 10 permit 0.0.0.0/0 le 19
$ns at 40 "$BGP2 command \"show ip bgp\""
BGP table version is 0, local router ID is 192.38.0.2At the 50th second of the simulation we reconfigure the prefix list so as to accept prefixes with mask length greater equal to 18:
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.10.0.0/19 192.38.0.1 0 1 i
Total number of prefixes 1
$ns at 50 "$BGP2 command \"no ip prefix-list PR_LIST seq 10 permit 0.0.0.0/0 le 19\""The modifications take effect only after the BGP session is reset.
$ns at 50 "$BGP2 command \"ip prefix-list PR_LIST seq 10 permit 0.0.0.0/0 ge 18\""
$ns at 51 "$BGP2 command \"clear ip bgp 1\""Finally, we confirm that our changes were effective.
$ns at 70 "$BGP2 command \"show ip bgp\""
BGP table version is 0, local router ID is 192.38.0.2The comfiguration files can be found here: ex2.tcl, bgpd1.conf, bgpd2.conf.
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.10.0.0/19 192.38.0.1 0 1 i
*> 10.10.10.0/24 192.38.0.1 0 1 i
*> 192.32.10.0 192.38.0.1 0 1 i
Total number of prefixes 3
Example 3
Suppose that we have five ASs with with the following interconnections:
First, we use an as-path list to configure router BGP5, to accept only routes originated in AS2 and deny all other routes advertised by BGP4.
This is accomplished with the following as-path access list.
router bgp 1To configure router 2 to allow networks originated in AS 1 and ASs directly attached to AS 1 we use the following configuration:
neighbor 192.38.0.4 remote-as 2
neighbor 192.38.0.4 route-map foo in
ip as-path access-list 1 permit ^2$
route-map foo permit 10
match as-path 1
router bgp 2
neighbor 192.38.0.1 remote-as 1
neighbor 192.38.0.1 route-map foo in
ip as-path access-list 1 permit ^1_[0-9]*$
route-map foo permit 10
match as-path 1
The log files confirm that router BGP5 installs in its routing table only the routes that are originated by AS2. Also BGP2 accepts routes that are originated by AS1 and AS6, while routes from AS7 are denied.
The files can be found here: ex3.tcl, bgpd1.conf, bgpd1.conf, bgpd1.conf, bgpd1.conf, bgpd1.conf, bgpd1.conf and bgpd2.conf.