Manual:BGP soft reconfiguration alternatives in RouterOS: Difference between revisions
manual |
|||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 8: | Line 8: | ||
or discard it altogether. | or discard it altogether. | ||
When the routing filters | When the routing filters change, they must be reapplied to routes from BGP (and other protocols, but we are focusing on BGP here). One way to do is reset BGP session, that is, tear down the connection with peer and re-establish it again. The disadvantage of this approach are obvious. | ||
Soft reconfiguration means that filtering policy can be reapplied after a change without session reset. For RouterOS, both dynamic and static variants are possible. | Soft reconfiguration means that filtering policy can be reapplied after a change without session reset. For RouterOS, both dynamic and static variants are possible. | ||
| Line 95: | Line 95: | ||
</div> | </div> | ||
[[Category:Manual]] | [[Category:Manual|B]] | ||
[[Category: Routing]] | [[Category: Routing|B]] | ||
[[Category: BGP]] | |||
[[Category:Case Studies|B]] | |||
Latest revision as of 14:37, 19 March 2014
Applies to RouterOS: v3, v4
What is soft reconfiguration?
When a route is received from a dynamic routing protocol, it is passed through routing filters. These filters may change some attributes of the route or discard it altogether.
When the routing filters change, they must be reapplied to routes from BGP (and other protocols, but we are focusing on BGP here). One way to do is reset BGP session, that is, tear down the connection with peer and re-establish it again. The disadvantage of this approach are obvious.
Soft reconfiguration means that filtering policy can be reapplied after a change without session reset. For RouterOS, both dynamic and static variants are possible.
Static soft-reconfiguration
What could be the effect of routing filters to a route? There are two possible cases.
CASE 1: Filters only change some attributes of the route. The orginal received attributes always are stored with the route. They are use to calculate new routing table attributes if filters changes. This process is trigerred automatically.
CASE 2: The route is discarded by filters. If the route is discarded, original attributes are not saved and information about it is lost. To avoid that, use action=reject in filters instead of action=discard. Now the route is saved, but is not eligible to become active (that is, it will not be installed in kernel routing table or redistributed to protocols).
- + Router does not lose routing information, because session is not reset.
- - Memory overhead for storing rejected routes.
Example:
Original configuration (routes are rejected):
[admin@A] > routing filter add chain=bgp-in action=reject prefix=4.0.0.0/8 prefix-length=8-32 [admin@A] > routing bgp peer set peer1 in-filter=bgp-in [admin@A] > ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC G GATEWAY DISTANCE INTERFACE 0 A S 0.0.0.0/0 10.0.0.1 1 ether1 1 ADb 3.0.0.0/8 192.65.184.3 200 ether1 2 Db 4.0.0.0/8 192.65.184.3 20 ether1 3 Db 4.21.104.0/24 192.65.184.3 20 ether1 4 Db 4.21.112.0/23 192.65.184.3 20 ether1 5 Db 4.21.130.0/23 192.65.184.3 20 ether1
Change filters to less restrictive:
[admin@A] > routing filter disable 0 [admin@A] > ip route pr Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC G GATEWAY DISTANCE INTERFACE 0 A S 0.0.0.0/0 10.0.0.1 1 ether1 1 ADb 3.0.0.0/8 192.65.184.3 200 ether1 2 ADb 4.0.0.0/8 192.65.184.3 200 ether1 3 ADb 4.21.104.0/24 192.65.184.3 200 ether1 4 ADb 4.21.112.0/23 192.65.184.3 200 ether1 5 ADb 4.21.130.0/23 192.65.184.3 200 ether1
Dynamic soft-reconfiguration
In this case, your BGP routing peer must support route refresh capability. Enter /routing bgp peer print status in CLI to check this.
- + No additional memory is used
- - Peer must support this capability.
- - It's not done automatically. You must issue /routing bgp peer refresh command after changes in filters are finished.
Example:
Original configuration (routes are discarded):
[admin@A] > routing filter add chain=bgp-in action=reject prefix=4.0.0.0/8 prefix-length=8-32 [admin@A] > ip route pr Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC G GATEWAY DISTANCE INTERFACE 0 A S 0.0.0.0/0 10.0.0.1 1 ether1 1 ADb 3.0.0.0/8 192.65.184.3 200 ether1
Change filters to less restrictive and send refresh request:
[admin@A] > routing filter disable 0 [admin@A] > routing bgp peer refresh peer1 [admin@A] > ip route pr Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC G GATEWAY DISTANCE INTERFACE 0 A S 0.0.0.0/0 10.0.0.1 1 ether1 1 ADb 3.0.0.0/8 192.65.184.3 200 ether1 2 ADb 4.0.0.0/8 192.65.184.3 200 ether1 3 ADb 4.21.104.0/24 192.65.184.3 200 ether1 4 ADb 4.21.112.0/23 192.65.184.3 200 ether1
Summary
- Do nothing unless the filter change changes discard status for some prefixes.
- Use routing bgp peer refresh comand after filter change if peer supports this capability.
- Use action=reject in filters in other cases.