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 cconsistent view of the interior routes of the AS is provided by the interior oruting 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).
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. More specifically, change instance AS number to the desired ASN and enable redistribution, if needed. One may configure instance output filter as well, but the same could be done on per peer basis.
[admin@MikroTik] > /routing bgp instance set default as=100 redistribute-static=yes [admin@rb11] > /routing bgp instance print Flags: X - disabled 0 as=100 router-id=0.0.0.0 redistribute-static=yes redistribute-connected=no redistribute-rip=no redistribute-ospf=no redistribute-other-bgp=no name="default" out-filter="" [admin@rb11] >
add at least one BGP peer. A peer is characterized by an IP address and an AS number. BGP instance name should be specified too, unless it is default as BGP peers are added to a particular instance.
[admin@rb11] > /routing bgp peer add remote-address=10.0.11.12 remote-as=200 [admin@rb11] > /routing bgp peer print Flags: X - disabled 0 remote-address=10.0.11.12 remote-as=200 multihop=no in-filter="" out-filter="" keepalive-time=0s hold-time=0s ttl=1 [admin@rb11] >
verify the connection is established, assuming other end is properly configured.
[admin@rb11] > /routing bgp peer print status Flags: X - disabled 0 remote-address=10.0.11.12 remote-as=200 multihop=no in-filter="" out-filter="" keepalive-time=0s hold-time=0s ttl=1 remote-id=10.123.11.27 remote-hold-time=0s used-hold-time=0s used-keepalive-time=0s state=established [admin@rb11] >
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: