Manual:BGP HowTo & FAQ
- 1 Problem: BGP session is not established
- 2 Problem: BGP session has been established, but routing updates are ignored
- 3 Question: How to check if a specific route exists in IP routing table?
- 4 Problem: Routes are exchanged and installed in IP route table, but they stay inactive
- 5 Question: How to filter out something?
- 6 Question: How to quickly check how many routes there are in route table?
- 7 Question: How to seen routes advertised to, and routes received from a particular peer?
- 8 Question: Is load balancing possible with MT BGP?
- 9 Question: How to announce routes?
- 10 Question: What does BGP network synchronize option exactly mean?
- 11 Question: How to control advertised routing information?
- 12 Problem: Looks like my routing filter isn't working
- 13 Question: How to announce just a single large IP prefix instead of many smaller (i.e. more specific) prefixes?
- 14 Question: How to aggregate IGP routes?
- 15 Question: How to advertise the default route?
- 16 Problem: Routes are announced, but with attributes not from IP routing table
- 17 Question: Can MT propagate BGP route updates without installing them in IP route table (i.e. serve as a pure route reflector)?
- 18 Question: Does MT BGP support 4-octet AS numbers?
- 19 Question: What are the specifics of MT BGP route selection algorithm?
- 20 Question: How much memory is required to keep the global BGP route table?
Problem: BGP session is not established
BGP uses TCP, so to discover the cause of the problem, you can start with testing TCP connectivity. One way to do that is as simple as /system telnet <remote-ip> 179 and check if the TCP connection can be established, and BGP port 179 is open and reachable.
If this is eBGP, make sure you have configured multihop=yes and TTL settings as needed. Use /routing bgp peer print status to see the current state of BGP connection.
Also note that if the remote peer is not supporting BGP Capabilities Advertisement (RFC 2842), some extra time will be needed for session establishment. The establishment will fail at the first time in this case, because of unknown options in BGP OPEN message. It should succeed at second attempt (i.e. after about a minute) and in any further attempts, because RouterOS will remember the offending options for that peer and not include them in BGP OPEN messages anymore.
Problem: BGP session has been established, but routing updates are ignored
NLRI (Network Layer Reachability Information) is ignored if path attributes are invalid. Turn on BGP debug logs to see the exact cause of the problem. (/system logging add topics=bgp,!raw).
One frequent case is unacceptable BGP next-hop. (Read here more about RouterOS and BGP next-hops.) In this case you must fix the next-hop on the sending side. In case the sender also is MT, you can use nexthop-choice peer setting to modify default next-hop selection preferences. If that fails, specify next-hop manually using set-out-nexthop routing filter.
Question: How to check if a specific route exists in IP routing table?
Finding a route by prefix is pretty fast:
/ip route print where dst-address = 126.96.36.199/24
To find all routes with prefixes falling in a range:
/ip route print where dst-address in 188.8.131.52/16
You can also search routes by other attributes, but it will be much slower and can take some time on a router having full BGP feed.
For example, since RouterOS 3.23 you can use this syntax to match routes having originated from a specific AS 30621:
[atis@SM_BGP] > /ip route print detail where bgp-as-path ~ "30621\$" Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 0 ADb dst-address=184.108.40.206/23 gateway=x.x.x.x recursive via y.y.y.y ether1 distance=20 scope=40 target-scope=10 bgp-as-path="2588,42979,702,701,7018,30621" bgp-origin=igp received-from=x.x.x.x 1 ADb dst-address=220.127.116.11/22 gateway=x.x.x.x recursive via y.y.y.y ether1 distance=20 scope=40 target-scope=10 bgp-as-path="2588,42979,702,701,7018,30621" bgp-atomic-aggregate=yes bgp-origin=igp received-from=x.x.x.x
Problem: Routes are exchanged and installed in IP route table, but they stay inactive
Routes must be resolved to become active; it's possible that you need to change scope or target-scope attributes for some routes.
Question: How to filter out something?
Use routing filters. For example, to filter out routes with a specific BGP community, add this rule:
/routing filter add bgp-communities=111:222 chain=bgp-in action=discard
Then tell BGP peer to use that filter chain:
/routing bgp peer set peer in-filter=bgp-in
There is also an out-filter BGP peer parameter for filtering outgoing BGP updates.
In recent RouterOS versions bgp-as-path filter accepts regular expressions. Community filtering by regular expressions is not yet possible.
Question: How to quickly check how many routes there are in route table?
For all routes use:
ip route print count-only
To see route count from a particular peer look at prefix-count property in:
route bgp peer print status
Question: How to seen routes advertised to, and routes received from a particular peer?
To see routes advertised to a particular peer (similar to Cisco command show ip bgp neighbor x.x.x.x advertised-routes) use:
routing bgp advertisements print
routing bgp advertisements print <peer_name>
To see routes received from a particular peer (similar to Cisco command show ip bgp neighbor x.x.x.x received-routes) use:
ip route print where received-from=<peer_name>
Question: Is load balancing possible with MT BGP?
Yes. Even though BGP itself cannot propagate multiple next-hops for a single route through the network, there are ways how to have routes with multiple next-hops on a router.
One way is to set multiple next-hops with routing filter.
routing filter add chain=bgp-in set-in-nexthop=10.0.1.1,10.0.2.1
Another way is to resolve BGP next-hop (if it is not directly reachable) through a static or OSPF route with multiple next-hops.
ip route add dst-address=x.x.x.x/y gateway=10.0.1.1,10.0.2.1
See also: BGP Load Balancing with two interfaces.
Question: How to announce routes?
If your don't have many routes to announce and want the best control over them, use BGP networks or aggregates. Note that both maximal BGP network and aggregate count is limited to 200.
Otherwise use route redistribution options, configurable under BGP instance settings.
Question: What does BGP network synchronize option exactly mean?
Since version 3.30 routing-test it means "do not announce this network, unless there is a matching active IGP or connected route in IP route table". "Matching" in this case means: with exactly the same prefix.
Question: How to control advertised routing information?
Use routing filters.
To advertise the same information (e.g. some BGP attribute value) to all peers, use BGP instance out-filter:
/routing filter add set-bgp-communities=111:222 chain=bgp-out /routing bgp instance set default out-filter=bgp-out
To send routing information to different peers, use peer specific filters. For example, if you want to advertise a lower preference value (higher path cost) to one of the peers, you can prepend your AS number multiple times to the BGP AS_PATH attribute:
/routing filter add set-bgp-prepend=4 chain=bgp-out-peer1 /routing bgp peer set peer1 out-filter=bgp-out-peer1
Use /routing bgp advertisements print to see what routing information exactly is advertised to peers.
Problem: Looks like my routing filter isn't working
Most likely prefix matcher is configured incorrectly. For example, say that you want to configure filter that will discard all routes falling under prefix 18.104.22.168/24.
The correct way to do this is with specifying prefix-length matcher:
add prefix=22.214.171.124/24 prefix-length=24-32 action=discard chain=bgp-in
This rule is incorrect (default netmask is /32, so it will match only prefix 126.96.36.199/32):
add prefix=188.8.131.52 prefix-length=24-32 action=discard chain=bgp-in
This is incorrect too (because it will match only route with netmask 255.255.255.0)
add prefix=184.108.40.206/24 action=discard chain=bgp-in
Use filter action log to see which routes are matched by a routing filter.
Question: How to announce just a single large IP prefix instead of many smaller (i.e. more specific) prefixes?
Use BGP aggregates if you need to aggregate multiple routes in a single one. An aggregate will be announced one if there are some active routes with more specific netmasks falling under it. When an aggregate becomes active, a corresponding blackhole route is a automatically created.
By default, BGP aggregates take in account only BGP routes. To also include IGP and connected routes in consideration, use include-igp configuration option.
Question: How to aggregate IGP routes?
Since 3.30 you can specify include-igp in BGP aggregate configuration. Example:
ip route add dst-address=10.9.9.0/25 gateway=10.0.0.1 ip route add dst-address=10.9.9.128/25 gateway=10.0.0.2 routing bgp aggregate add instance=default prefix=10.9.9.0/24 include-igp=yes
[admin@MikroTik] > routing bgp advertisements print PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF peer1 10.9.9.0/24 10.0.0.131 incomplete
Use routing filters to control which routes are aggregated. For example, if you don't want to aggregate connected routes:
routing filter add chain=aggregate-out protocol=connect action=discard routing bgp aggregate set [find] advertise-filter=aggregate-out
Question: How to advertise the default route?
To send default route to a particular peer, set default-originate=always or if-installed for that peer.
Problem: Routes are announced, but with attributes not from IP routing table
There exists a limitation in MT BGP operation: if a BGP network with synchronization turned off, or default route generated by default-originate=always configuration statement is announced, the attributes of that route will not be taken from routing table.
If synchronize=yes or default-originate=if-installed is used, the attributes of the announced route will be taken from routing table.
Question: Can MT propagate BGP route updates without installing them in IP route table (i.e. serve as a pure route reflector)?
No, it's not possible.
Question: Does MT BGP support 4-octet AS numbers?
Yes. For input, both ASPLAIN (i.e. xxxxxx) and ASDOT (i.e. xxx.xxx) formats are supported; for output, ASPLAIN only.
Question: What are the specifics of MT BGP route selection algorithm?
The algorithm is described here. The algorithm follows BGP RFC closely, with a few differences:
- Cisco-style weight is used as the first and most important selection criteria;
- AS path length comparison can be turned off by a configuration parameter;
- locally originated BGP routes are preferred in case of same AS path length, weight, and local-preference values;
- interior cost calculation and comparison step is skipped.
The algorithm is used only to compare BGP routes from the same BGP instance. For different instances, only "distance" attributes are compared.
Question: How much memory is required to keep the global BGP route table?
Our recommendations are at least 256 MB RAM for a single copy of the table and at least 512 MB RAM for two or three copies.
Assuming the Internet route table size ~300 000 routes, for the first copy of the table, with routes resolved and active, about 155 MB extra memory is needed. This is only for the first copy specifically, the amount of RAM needed for each additional copy of the table is significantly less than that number.
RAM usage on RB1000 (BGP feed size 301 480 routes, no redistribution):
- No BGP routes: 26 MB
- Single copy: 181 MB
- Two copies: 241 MB
- Three copies: 299 MB
Memory requirements will increase if incoming routing filters that change route attributes are used. That happens because unchanged copy of the route attributes received also will be stored in RAM, to be used in case of later routing filter change.
The requirements will also increase depending on count of peers to which routes are advertised.
It is not recommended to turn on SNMP on routers with full BGP feed!