Manual:BGP Case Studies: Difference between revisions
No edit summary |
m moved BGP Case Studies to Manual:BGP Case Studies |
||
(No difference)
| |||
Revision as of 15:26, 11 March 2010
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). File:IBGP eBGP.jpg
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:
[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.
File:BGP redistribution simple.jpg
- To enable the router R3 to advertise static networks to its peers:
/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"
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] >
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=""
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