Manual:Limiting maximum number of prefixes accepted: Difference between revisions

From MikroTik Wiki
Jump to navigation Jump to search
No edit summary
Line 39: Line 39:


[[Category:Routing]]
[[Category:Routing]]
[[Category:Manual]]
[[Category:Case Studies]]

Revision as of 13:41, 7 May 2010

Misconfiguration of BGP routers occasionaly lead to an injection of large route tables in BGP routing system. To protect your network against such "route leaks", you can limit maximum prefix count accepted.

Configuration settings:

max-prefix-limit (integer, default: unlimited) - maximum number of prefixes accepted from specific peer. After this limit is exceeded, TCP connection between peers is tear down.

max-prefix-restart-time (seconds) - minimum time interval after which peers can reestablish BGP session.
default - infinity, i.e. session is not reestablished without manual intervention.

Example:

[admin@A] > routing bgp peer set peer1 max-prefix-limit=10000 max-prefix-restart-time=3600
[admin@A] > routing bgp peer print
 0   name="peer1" instance=default remote-address=159.148.xx.xx remote-as=64550
     tcp-md5-key="" nexthop-choice=default multihop=yes route-reflect=no
     hold-time=3m ttl=100 max-prefix-limit=10000 max-prefix-restart-time=1h
     in-filter="" out-filter=""

To observe how many prefixes from a particular peer are installed in the routing table, pay attention to prefix-count attribute:

[admin@A] > routing bgp peer print status  
 0   name="peer1" instance=default remote-address=159.148.xx.xx remote-as=64550
     tcp-md5-key="" nexthop-choice=default multihop=yes route-reflect=no
     hold-time=3m ttl=100 max-prefix-limit=10000 max-prefix-restart-time=1h
     in-filter="" out-filter="" remote-id=10.0.11.155 uptime=1m33s prefix-count=628
     updates-sent=1 updates-received=762 withdrawn-sent=0 withdrawn-received=0
     remote-hold-time=3m used-hold-time=3m used-keepalive-time=1m
     refresh-capability=yes state=established

Caveats

Negative effects of this mechanism are complete routing breakdown after BGP session is destroyed. Most probably routing will be broken until manual intervention of network operator that could take hours.

Theoretically this can be imporved using max-prefix-restart-time, but obviously until the situation is not fixed at remote peer's end, session will be destroyed repeatedly.

In short, this feature is acceptable as an emergency means. It is not a replacement for full-scale routing filters. ISPs should only accept prefixes which have been assigned or allocated to their downstream peer and filter out everything else.