On Mon, Nov 9, 2015 at 9:52 PM, Alexis Rosen <
quagga-us...@alexis.users.panix.com> wrote:
> On Nov 9, 2015, at 8:21 PM, Donald Sharp <sha...@cumulusnetworks.com>
> wrote:
> > From: Dinesh G Dutt <dd...@cumulusnetworks.com>
> >
> > Currently, modifications to route maps do not affect already processed
> > routes; they only affect new route updates. This patch addresses this
> > limitation.
>
> This is highly desirable, from one point of view, both as a significant
> convenience and because it keeps tripping up newbies who wonder why their
> changes aren't having any effect.
>
> However... the current behavior is consistent with Cisco's since the
> beginning of time, and is well understood by most. More, it allows multiple
> changes to be made in batches, without having to worry about inconsistent
> states during those changes. While the existing behavior is easy enough to
> deal with (clear ip bgp...), there is no easy way to get the existing
> behavior once this patch is in.
>
Cisco IOS behaves the same way as quagga with the proposed
patch...route-maps are applied automatically after a few seconds. Example:
#3550 running 15.0(2)SE6, 10.0.3.34 is quagga
!
router bgp 65001
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 10.0.3.34 remote-as 10
!
address-family ipv4
network 1.1.1.1 mask 255.255.255.255 route-map SET_COMM_11
network 2.2.2.2 mask 255.255.255.255 route-map SET_COMM_22
network 3.3.3.3 mask 255.255.255.255 route-map SET_COMM_33
neighbor 10.0.3.34 activate
neighbor 10.0.3.34 send-community
neighbor 10.0.3.34 route-map FOO out
exit-address-family
!
ip bgp-community new-format
ip community-list standard COMM_11 permit 1:1
ip community-list standard COMM_22 permit 2:2
ip community-list standard COMM_33 permit 3:3
!
ip route 1.1.1.1 255.255.255.255 Null0
ip route 2.2.2.2 255.255.255.255 Null0
ip route 3.3.3.3 255.255.255.255 Null0
!
route-map FOO permit 10
!
route-map FOO deny 100
!
route-map SET_COMM_11 permit 10
set community 1:1
!
route-map SET_COMM_22 permit 10
set community 2:2
!
route-map SET_COMM_33 permit 10
set community 3:3
!
On quagga we RX all three prefixes as expected:
superm-redxp-05# show ip bgp
BGP table version is 9, local router ID is 10.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, =
multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.0.1.131 0 0 65001 i
*> 2.2.2.2/32 10.0.1.131 0 0 65001 i
*> 3.3.3.3/32 10.0.1.131 0 0 65001 i
Total number of prefixes 3
superm-redxp-05#
I tweak the outbound route-map to only permit the 2.2.2.2/32 route:
cis-3550-01(config-route-map)#route-map FOO permit 10
cis-3550-01(config-route-map)#match community COMM_22
A few seconds later IOS automatically applies the change and we now only RX
the 2.2.2.2/32 route.
superm-redxp-05# show ip bgp
BGP table version is 11, local router ID is 10.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, =
multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 10.0.1.131 0 0 65001 i
Total number of prefixes 1
superm-redxp-05#
> While I appreciate the convenience it provides, I can also see this patch
> being a significant PITA from time to time. So I would suggest the ability
> to go either way, based on a CLI command. The simple version would simply
> switch behavior between the two modes; a more complex version would queue
> up changes while "holding" them, and then process them all as soon as the
> hold is released. ISTM that the more complex version would be a really nice
> feature to have, but since I'm not writing the code, I'm not going to
> complain either way.
>
The user could do this by setting the timer to 0, make their changes and
then set the timer to non-zero (or leave it at zero and soft clear all
peers).
superm-redxp-05(config-router)# bgp route-map delay-timer ?
<0-600> *0 disables the timer,* no route updates happen when route-maps
change
superm-redxp-05(config-router)#
Daniel
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
