Manual:BGP Case Studies
A good place to start learning about BGP in MikroTik RouterOS.
Note: The following applies to "routing-test" package only
What Is BGP?
The Border Getaway Protocol (BGP) is an interautonomous system routing protocol based on distance-vector algorithm. It is used to exchange routing information across the Internet and is the only protocol that is designed to deal with a network of the Internet's size and the only protocol that can deal well with having multiple connections to unrelated routing domains.
How Does BGP Work?
BGP operates by exchanging network layer reachability information (NLRI). This information contains an indication to a what sequene of full paths (BGP AS numbers) the route should take in order to reach destination network (NLRI prefix).
BGP routers exchange reachability information by means of a transport protocol, which in case of BGP is TCP (port 179). Upon forming a TCP connection these routers exchange initial messages to negotiate and confirm connection parameters.
Any two routers that have established TCP connection to exchange BGP routing information are called peers, or neighbours. The peers initially exchange their full routing tables. After the initial exchange incremental updates are sent as the routing tables change. Thus, BGP does not require periodic refresh of the entire BGP routing table. BGP maintains routing table version number which must be the same between any two given peers for the duration of the connection. KeepAlive messages are sent periodically to ensure that the connection is up and runnig. BGP sends notification messages in responce to errors or special conditions.
TCP protocol connection between two peers is closed when either an error has occured or no update messages or KeepAlive messages has been received during the period of BGP Hold Timer.
iBGP and eBGP
A particular AS might have multile BGP speakers and provide transit service to other ASs. This implies that BGP speakers must maintain a consistent view of routing within the AS. A consistent view of the interior routes of the AS is provided by the interior routing protocol such as OSPF or RIP. A consistent view of the routes exterior to the AS is provided by having all BGP routers within the AS establishing direct BGP connections with each other.
Using a set of administrative policies BGP speakers within the AS arrive to an agreement as to which entry/exit point to use for a particular destination. This information is communicated to the interior routers of the AS using interior routing protocol.
Two BGP neighbors from different ASs are said to maintain an "external" link. Similarly, a BGP peer in a different AS is referred to as an external peer. BGP connections between peers within the same AS are known as "internal" links. BGP speakers that are connected by internal link are referred as internal peers. As far as this paper is concerned, iBGP refers to the BGP session between two peers in the same AS, or internal link. In turn, eBGP refers to the links between external BGP peers (these that are in different ASs). File:IBGP eBGP.jpg
To enable BGP assuming only one BGP process will be present in the system, it is enough to do the following:
- modify configuration of the default BGP instance. In particular, change instance AS number to the desired ASN:
[admin@rb11] > /routing bgp instance set default as=100 redistribute-static=no [admin@rb11] > /routing bgp instance print Flags: X - disabled 0 as=100 router-id=0.0.0.0 redistribute-static=no redistribute-connected=no redistribute-rip=no redistribute-ospf=no redistribute-other-bgp=no name="default" out-filter="" [admin@rb11] >
Note, that, unless explicitly specified, BGP router ID is set as the highest IP address on the interface.
- add at least one BGP peer. Refer to the next section for more information on how to configure BGP peers.
Two BGP routers have to establish TCP connection between each other to be considered as BGP peers. Since BGP requires a reliable transport for routing information, a TCP connection is essential for it to operate properly.
Once TCP connection is up, routers exchange some initial information such as the BGP router ID, the BGP version, the AS number and the Hold Time interval value in the OPEN message. After these values are communicated and agreed upon, the BGP session is established and the routers are ready to exchange routing information via BGP UPDATE messages.
To establish TCP connection to another BGP router, issue the following command:
[eugene@SM_BGP] > /routing bgp peer add remote-address=10.20.1.210 remote-as=65534 [eugene@SM_BGP] > /routing bgp peer print Flags: X - disabled 0 instance=default remote-address=10.20.1.210 remote-as=65534 tcp-md5-key="" multihop=no route-reflect=no hold-time=3m ttl=3 in-filter="" out-filter="" [eugene@SM_BGP] >
Issue the following command to verify the connection is established:
[eugene@SM_BGP] > /routing bgp peer print status Flags: X - disabled 0 instance=default remote-address=10.20.1.210 remote-as=65534 tcp-md5-key="" multihop=no route-reflect=no hold-time=3m ttl=3 in-filter="" out-filter="" remote-id=10.20.1.210 uptime=1d1h43m16s prefix-count=180000 remote-hold-time=3m used-hold-time=3m used-keepalive-time=1m refresh-capability=yes state=established [eugene@SM_BGP] >
The BGP connection between two peers is up (state=established) with used value of Hold Time of 3 minutes. The prefix-count parameter indicates the total number of prefixes received from this particular peer. In case a peer later withdraws some prefixes from its routing announcements, the total number of prefixes is reduced by the appropriate value.
BGP process does not redistribute routes by default. You need to set one or more of the redistribute-connected, redistribute-static, redistribute-rip, redistribute-ospf and redistribute-other-bgp BGP instance parameters to yes to enable redistribution of the routes of the particular type. Thus issuing the /routing bgp instance set default redistribute-static=yes redistribute-connected=yes command enables redistribution of static and connected routes to all BGP peers that are configured to use default BGP instance. This might not be the desired behaviour, since now you are announcing all of your internal routes into BGP. Moreover, some of the advertized prefixes might be too small and should be substituted vith larger ones. You need to apply routing filters to avoid these problems.
Unfiltered redistribution of routes might lead to wrong results. Consider the example below. R3 has a static route to the 192.168.0.0/24 network and since it has redistribute-static set to yes it announces the route to its BGP peer R1. This makes R1 believe that the AS300 is the source of the 192.168.0.0/24 network, which is misleading. To avoid this problem a routing filter that permits redistribution only of the 192.168.11.0/24 network must be applied on the R3.
- On R3:
- On R1:
BGP allows to specify some arbitrary prefixes to be unconditionally advertised. These prefixes should be added to the /routing bgp networks list. The prefixes in this list are advertised as IGP routes. The redistribution of the BGP networks is not affected by the routing filters. BGP networks also do not affect aggregate processing.
Issue the following command to make the router advertise the 192.168.0.0/24 network to its peers:
[eugene@SM_BGP] > /routing bgp network add network=192.168.0.0/24 [eugene@SM_BGP] > /routing bgp network print Flags: X - disabled # NETWORK 0 192.168.0.0/24 [eugene@SM_BGP] >
Note: consider aggregates as an alternative to BGP networks.
You could always use a static route to originate a subnet. With the routing-test package bringing many bgp-related enhancements into the /ip route menu, the static routes become a more powerful tool to originate prefixes. For example, you could add a static route to the 10.8.0.0/16 network and set BGP Local Preference attribute value for this route simultaneously:
/ip route add dst-address=10.8.0.0/16 gateway=10.0.11.1 bgp-local-pref=110 [admin@MikroTik] > /ip ro print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf # DST-ADDRESS PREF-SRC G GATEWAY DISTANCE INTERFACE 0 A S 0.0.0.0/0 r 10.0.11.1 1 ether1 1 ADC 10.0.11.0/24 10.0.11.51 0 ether1 2 A S 10.8.0.0/16 r 10.0.11.1 1 ether1 3 ADC 10.12.0.0/24 10.12.0.2 0 bonding1 [admin@MikroTik] > ==Getting Route Information==