Manual:BGP Case Studies 1

Manual:BGP Case Studies

A good place to start learning about BGP in MikroTik RouterOS.

What is BGP?
The Border Getaway Protocol (BGP) is an inter-autonomous 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.
BGP is designed to allow for sophisticated administrative routing policies to be implemented. BGP does not
exchange information about network topology but rather reachability information. As such, BGP is better suited to
inter-AS environments and special cases like informational feeds. If you just need to enable dynamic routing in your
network, consider OSPF instead.

How Does BGP Work?

BGP operates by exchanging network layer reachability information (NLRI). This information contains an indication
to a what sequence 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
neighbors. 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 running. BGP sends
notification messages in response 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 multiple 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).
Manual:BGP Case Studies 2

Enabling BGP
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 least IP address on the router.
• add at least one BGP peer. Refer to the next section for more information on how to configure BGP peers.

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:

Manual:BGP Case Studies 3

[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.

Route Redistribution
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 behavior, since now you
are announcing all of your internal routes into BGP. Moreover, some of the advertised prefixes might be too small
and should be substituted with larger ones. You need to configure routing filters and route aggregation to avoid these
problems.

Routing Filters
Unfiltered redistribution of routes might lead to undesired 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.

• To enable the router R3 to advertise static networks to its peers:

Manual:BGP Case Studies 4

/routing bgp instance set default redistribute-static=yes

• To filter out all prefixes except the 192.168.11.0/24 network:

/routing filter add chain=to_R1 prefix=192.168.11.0/24 invert-match=yes action=discard

/routing bgp peer set R1 out-filter=to_R1

Note the invert-match parameter. It makes the rule to match everything except the 192.168.11.0/24 prefix and
discard it.
Routing filters are accessible through /routing filter menu. A routing filter consists of one or more filter rules
identified by common chain. Rules are processed from top to bottom. Each rule consists of condition(s) to be
satisfied in order for rule to match and action(s) to be performed on the matched prefixes. To enable routing filter,
specify corresponding chain name as either in-filter or out-filter for BGP peer, or as out-filter for BGP instance.

Routing Filter Example

[eugene@SM_BGP] routing filter> print chain=Latnet-in
Flags: X - disabled
0 chain=Latnet-in prefix=10.0.0.0/8 prefix-length=8-32 invert-match=no action=discard

1 chain=Latnet-in prefix=192.168.0.0/16 invert-match=no action=discard

2 chain=Latnet-in prefix=169.254.0.0/16 invert-match=no action=discard

3 chain=Latnet-in prefix=4.23.113.0/24 invert-match=no action=passthrough

set-bgp-communities=64550:14

4 chain=Latnet-in prefix=4.36.116.0/23 invert-match=no action=passthrough set-routing-mark="LAN"

set-route-comment="Remote offices"

5 chain=Latnet-in prefix=8.8.0.0/16 prefix-length=16-32 bgp-communities=2588:800 invert-match=no

action=discard
[eugene@SM_BGP] routing filter>

• rule #0 matches prefix 10.0.0.0/8 and more specific prefixes like 10.0.1.0/24, 10.1.23.0/28, etc. and discards them
(these prefixes are silently dropped from inbound update messages and do not appear in memory)
• rule #3 sets BGP COMMUNITY attribute for prefix 4.23.113.0/24
• rule #4 has two actions. It simultaneously sets routing mark and comment for route to 4.36.116.0/23
• rule #5 discards prefix 8.8.0.0/16 and more specific ones, if they have COMMUNITY attribute of 2588:800
To use the filter above, add it as in-filter to the Latnet peer:
[eugene@SM_BGP] routing bgp peer> set Latnet in-filter=Latnet-in
[eugene@SM_BGP] routing filter> print
Flags: X - disabled
0 name="C7200" instance=latnet remote-address=10.0.11.202 remote-as=64527 tcp-md5-key=""
nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=1 in-filter=""
out-filter=to_C7200

1 name="Latnet" instance=latnet remote-address=10.0.11.55 remote-as=2588 tcp-md5-key=""

nexthop-choice=default multihop=yes route-reflect=no hold-time=3m ttl=5 in-filter="Latnet-in"
Manual:BGP Case Studies 5

out-filter=to_Latnet

8 name="gated" instance=latnet remote-address=10.0.11.20 remote-as=64550 tcp-md5-key=""

nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=1 in-filter=""
out-filter=""

[eugene@SM_BGP] routing bgp peer>

BGP Networks
The information in this article may be deprecated, and is described better elsewhere in the Wiki.

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 affected by peer's routing filters. On the other
hand, BGP networks are not installed in main routing table. As a consequence, they are not
considered in best path selection algorithm, and 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.

Static Routes
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] >
Manual:BGP Case Studies 6

BGP Advertisements
RouterOS provides a way to view what prefixes the router is redistributing to its peers. Issue /routing bgp
advertisements print <peer's address> command to view prefixes sent to this peer.
[eugene@SM_BGP] routing bgp advertisements> print 10.0.11.20

# DST-ADDRESS NEXTHOP AS-PATH ORIGIN LOCAL-PREF MED

0 3.0.0.0/8 159.148.254.250 2588,6747,1299,701,703,80 igp 100

1 4.0.0.0/8 10.0.11.155 2588,6747{174,1273,1299,2914... igp 100

2 6.0.0.0/8 10.0.11.155 2588,6747,1299,701,668 igp 100

3 8.0.0.0/8 159.148.254.250 2588,6747,1299,3356 igp 100

4 8.0.0.0/9 159.148.254.250 2588,6747,1299,3356 igp 100

5 8.2.64.0/23 159.148.254.250 2588,6747,1299,3356,16803 igp 100

6 8.2.144.0/22 159.148.254.250 2588,6747,1299,3356,36394 igp 100

7 8.3.12.0/24 159.148.254.250 2588,6747,1299,3356,14711 igp 100

8 8.3.13.0/24 159.148.254.250 2588,6747,1299,3356,26769 igp 100

9 8.3.15.0/24 159.148.254.250 2588,6747,1299,3356,14711 igp 100

10 8.3.17.0/24 159.148.254.250 2588,6747,1299,25973 igp 100

11 8.3.19.0/24 159.148.254.250 2588,6747,1273,22822,26769 igp 100

12 8.3.37.0/24 159.148.254.250 2588,6747,1299,3356,3356,21640 igp 100

13 8.3.38.0/23 159.148.254.250 2588,6747,1299,3549,16420 igp 100

14 8.3.46.0/24 159.148.254.250 2588,6747,1299,3356,3356,21640 igp 100

15 8.3.208.0/24 159.148.254.250 2588,6747,1299,3549,36431 igp 100

16 8.3.209.0/24 159.148.254.250 2588,6747,1273,22822,26769 igp 100

17 8.3.210.0/24 159.148.254.250 2588,6747,1299,27524 igp 100

18 8.3.216.0/24 159.148.254.250 2588,6747,1299,3356,15170 igp 100

19 8.4.86.0/24 159.148.254.250 2588,6747,1299,3356,14627 igp 100

20 8.4.96.0/20 159.148.254.250 2588,6747,1299,3356,15162 igp 100

21 8.4.113.0/24 159.148.254.250 2588,6747,1299,3356,15162 igp 100

22 8.4.224.0/24 159.148.254.250 2588,6747,1299,3356,13546 igp 100

23 8.5.192.0/22 159.148.254.250 2588,6747,1299,209,13989 igp 100

24 8.6.48.0/21 159.148.254.250 2588,6747,1299,3356,36492 igp 100

25 8.6.89.0/24 159.148.254.250 2588,6747,1299,3356,11734 igp 100

26 8.6.90.0/24 159.148.254.250 2588,6747,1299,3356,16541 igp 100

27 8.6.220.0/22 159.148.254.250 2588,6747,1299,3356,13680 igp 100

[eugene@SM_BGP] routing bgp advertisements>

BGP Aggregates
This feature allows to redistribute one big prefix instead of many smaller ones.
[eugene@SM_BGP] routing bgp aggregate> print

Flags: X - disabled

0 prefix=3.0.0.0/8 summary-only=yes inherit-attributes=yes attribute-filter="" suppress-filter=""

advertise-filter=""

1 prefix=6.0.0.0/8 summary-only=yes inherit-attributes=yes attribute-filter="" suppress-filter=""

advertise-filter=""
Manual:BGP Case Studies 7

2 prefix=4.0.0.0/8 summary-only=yes inherit-attributes=yes attribute-filter="" suppress-filter=""

advertise-filter=""

[eugene@SM_BGP] routing bgp aggregate>

The rules above suppress specific prefixes in ranges 3.0.0.0/8, 6.0.0.0/8 and 4.0.0.0/8 from being advertised:
[eugene@SM_BGP] routing bgp advertisements> print 10.0.11.20

# DST-ADDRESS NEXTHOP AS-PATH ORIGIN LOCAL-PREF MED

0 3.0.0.0/8 159.148.254.250 2588,6747,1299,701,703,80 igp 100

1 4.0.0.0/8 10.0.11.155 2588,6747{174,1273,1299,2914... igp 100

2 6.0.0.0/8 10.0.11.155 2588,6747,1299,701,668 igp 100

3 8.0.0.0/8 159.148.254.250 2588,6747,1299,3356 igp 100

4 8.0.0.0/9 159.148.254.250 2588,6747,1299,3356 igp 100

5 8.2.64.0/23 159.148.254.250 2588,6747,1299,3356,16803 igp 100

Article Sources and Contributors 8

Article Sources and Contributors

Manual:BGP Case Studies  Source: http://wiki.mikrotik.com/index.php?oldid=16876  Contributors: Atis, Eep, Eugene, Hellbound, Janisk, Marisb, Route, SergejsB

Image Sources, Licenses and Contributors

Image:IBGP eBGP.jpg  Source: http://wiki.mikrotik.com/index.php?title=File:IBGP_eBGP.jpg  License: unknown  Contributors: Eugene
Image:BGP redistribution simple.jpg  Source: http://wiki.mikrotik.com/index.php?title=File:BGP_redistribution_simple.jpg  License: unknown  Contributors: Eugene
Image:Icon-important.png  Source: http://wiki.mikrotik.com/index.php?title=File:Icon-important.png  License: unknown  Contributors: Marisb, Route