Manual:BGP HowTo & FAQ: Difference between revisions

From MikroTik Wiki
Jump to navigation Jump to search
No edit summary
m (add TOC)
Line 1: Line 1:
'''''Problem:''' BGP is not connecting''
__FORCETOC__
 
====<i>Problem:</i> BGP is not connecting====


:BGP uses TCP, you can start with testing TCP connectivity. One way to do that is as simple as '''/system telnet <remote-ip> 179'''. The result you see should be something like this: ''"Connection closed by foreign host"''. This means BGP port (179) is open and reachable.
:BGP uses TCP, you can start with testing TCP connectivity. One way to do that is as simple as '''/system telnet <remote-ip> 179'''. The result you see should be something like this: ''"Connection closed by foreign host"''. This means BGP port (179) is open and reachable.
Line 7: Line 9:
:Also note that if the remote peer is not supporting BGP Capabilities Advertisement (RFC 2842), some extra time will be needed for session establishment.
:Also note that if the remote peer is not supporting BGP Capabilities Advertisement (RFC 2842), some extra time will be needed for session establishment.


 
====<i>Problem:</i> BGP connection is established, but routing updates are ignored====
'''''Problem:''' BGP connection is 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'').
: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'').
Line 14: Line 15:
:One frequent case is unacceptable BGP nexthop. (Read [[BGP nexthop selection and validation in RouterOS 3.x|here]] more about RouterOS and BGP nexthops.) In this case you must fix the nexthop on the sending side. In case the sender also is MT, you can use '''nexthop-choice''' peer setting to modify default nexthop selection preferences. If that fails, specify nexthop manually using '''set-out-nexthop''' routing filter.
:One frequent case is unacceptable BGP nexthop. (Read [[BGP nexthop selection and validation in RouterOS 3.x|here]] more about RouterOS and BGP nexthops.) In this case you must fix the nexthop on the sending side. In case the sender also is MT, you can use '''nexthop-choice''' peer setting to modify default nexthop selection preferences. If that fails, specify nexthop manually using '''set-out-nexthop''' routing filter.


 
====<i>Question:</i> How to check if a specific route exists in IP routing table?====
'''''Question:''' How to check if a specific route exists in IP routing table?''


:Finding a route by prefix is pretty fast:
:Finding a route by prefix is pretty fast:
Line 40: Line 40:
         bgp-atomic-aggregate=yes bgp-origin=igp received-from=x.x.x.x
         bgp-atomic-aggregate=yes bgp-origin=igp received-from=x.x.x.x


 
====<i>Problem:</i> Routes are exchanged and installed in IP route table, but they stay inactive====
'''''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 [[Using scope and target-scope attributes|scope or target-scope attributes]] for some routes.
:Routes must be resolved to become active; it's possible that you need to change [[Using scope and target-scope attributes|scope or target-scope attributes]] for some routes.


 
====<i>Question:</i> How to announce just a single large IP prefix instead of many smaller (i.e. more specific) prefixes?====
'''''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 BGP routes in a single one. An aggregate will be announced one if there are some active BGP routes falling under it. When an aggregate becomes active, a corresponding blackhole route is a automatically created.
:Use BGP aggregates if you need to aggregate multiple BGP routes in a single one. An aggregate will be announced one if there are some active BGP routes falling under it. When an aggregate becomes active, a corresponding blackhole route is a automatically created.
Line 52: Line 50:
:If the smaller prefixes belong to IGP or static routes instead, simply configure a BGP network and filter out all unneeded smaller prefixes. Specify '''synchronize=yes''' in BGP network parameters if you want to announce the network only when there are some active underlying IGP routes.
:If the smaller prefixes belong to IGP or static routes instead, simply configure a BGP network and filter out all unneeded smaller prefixes. Specify '''synchronize=yes''' in BGP network parameters if you want to announce the network only when there are some active underlying IGP routes.


 
====<i>Problem:</i> I want to aggregate IGP routes, but it seems that BGP aggregates are not working.====
'''''Problem:''' I want to aggregate IGP routes, but it seems that BGP aggregates are not working.''


:BGP aggregates take in account only BGP routes. To create configuration with the same effect on IGP routes, do the following:
:BGP aggregates take in account only BGP routes. To create configuration with the same effect on IGP routes, do the following:
Line 59: Line 56:
:#Add routing filter to filter out unneeded advertisements
:#Add routing filter to filter out unneeded advertisements


====<i>Question:</i> How to advertise the default route?====


'''''Question:''' How to advertise the default route?''
:To send default route to a particular peer, set '''default-originate=always''' for that peer.
 
:To send default route to a particular peer, set '''originate-default=yes''' for that peer.


 
====<i>Question:</i> How to filter out something?====
'''''Question:''' How to filter out something?''


:Use routing filters. For example, to filter out routes with a specific BGP community, add this rule:
:Use routing filters. For example, to filter out routes with a specific BGP community, add this rule:
Line 77: Line 72:
:Note that since RouterOS 3.16, using routing-test package, '''bgp-as-path''' filter accepts regular expressions.
:Note that since RouterOS 3.16, using routing-test package, '''bgp-as-path''' filter accepts regular expressions.


 
====<i>Question:</i> How to control advertised routing information?====
'''''Question:''' How to control advertised routing information?''


:Use routing filters.
:Use routing filters.
Line 92: Line 86:
:Use ''/routing bgp advertisements print'' to see what routing information exactly is advertised to peers.
:Use ''/routing bgp advertisements print'' to see what routing information exactly is advertised to peers.


 
====<i>Problem:</i> Looks like my routing filter isn't working====
'''''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 1.1.1.0/24.
:Most likely prefix matcher is configured incorrectly. For example, say that you want to configure filter that will discard all routes falling under prefix 1.1.1.0/24.
Line 112: Line 105:
:Use filter action ''log'' to see which routes are matched by that filter.
:Use filter action ''log'' to see which routes are matched by that filter.


 
====<i>Question:</i> Can MT propagate BGP route updates without installing them in IP route table (i.e. serve as a pure route reflector)?====
'''''Question:''' Can MT propagate BGP route updates without installing them in IP route table (i.e. serve as a pure route reflector)?''


:No.
:No.


[[Category:Routing]]
[[Category:Routing]]

Revision as of 10:28, 10 July 2009


Problem: BGP is not connecting

BGP uses TCP, you can start with testing TCP connectivity. One way to do that is as simple as /system telnet <remote-ip> 179. The result you see should be something like this: "Connection closed by foreign host". This means BGP port (179) is open and reachable.
If this is eBGP, make sure you have configured multihop=yes and TTL 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.

Problem: BGP connection is 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 nexthop. (Read here more about RouterOS and BGP nexthops.) In this case you must fix the nexthop on the sending side. In case the sender also is MT, you can use nexthop-choice peer setting to modify default nexthop selection preferences. If that fails, specify nexthop 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 = 193.23.33.0/24
To find all routes with prefixes falling in a range:
/ip route print where dst-address in 193.23.0.0/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=12.151.74.0/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=12.151.76.0/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 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 BGP routes in a single one. An aggregate will be announced one if there are some active BGP routes falling under it. When an aggregate becomes active, a corresponding blackhole route is a automatically created.
If the smaller prefixes belong to IGP or static routes instead, simply configure a BGP network and filter out all unneeded smaller prefixes. Specify synchronize=yes in BGP network parameters if you want to announce the network only when there are some active underlying IGP routes.

Problem: I want to aggregate IGP routes, but it seems that BGP aggregates are not working.

BGP aggregates take in account only BGP routes. To create configuration with the same effect on IGP routes, do the following:
  1. Configure a BGP network with synchronize=yes
  2. Add routing filter to filter out unneeded advertisements

Question: How to advertise the default route?

To send default route to a particular peer, set default-originate=always for that peer.

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.
Note that since RouterOS 3.16, using routing-test package, bgp-as-path filter accepts regular expressions.

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 1.1.1.0/24.
This rule is incorrect:
add prefix=1.1.1.0 action=discard chain=bgp-in
Default netmask is /32, so it will match only prefix 1.1.1.0/32
This is incorrect too:
add prefix=1.1.1.0/24 action=discard chain=bgp-in
This will match only route with netmask 255.255.255.0.
The correct way to do this is to also specify prefix-length matcher:
add prefix=1.1.1.0/24 prefix-length=24-32 action=discard chain=bgp-in
Or (the same effect):
add prefix=1.1.1.0 prefix-length=24-32 action=discard chain=bgp-in
Use filter action log to see which routes are matched by that filter.

Question: Can MT propagate BGP route updates without installing them in IP route table (i.e. serve as a pure route reflector)?

No.