So I have found this behavior too. It was kinda funny to read about all those soft and hard resets you need to do in order to implement policy change. And then you see it is being implemented automatically even with route refresh ( and/or any other negotiated capability) turned of. As log messages suggest it has something to do with two things: - Timer: I looked at all possibly relevant settings under "sh run all", nothing usefull there unfortunately. - Group: in BGP debug you may see that 'group' is mentioned several times BGP: TX IPv4 Unicast Tab Policy change timer expired. BGP: TX IPv4 Unicast Mem global 10.7.2.2 Changing state from BLOCKED to WAIT (pending advertised bit allocation). BGP: TX IPv4 Unicast Mem global 10.7.2.2 Match with group 5 failed (outbound routemap). BGP: TX IPv4 Unicast Mem global 10.7.2.2 Match with group 7 failed (internal/external). BGP: TX IPv4 Unicast Mem global 10.7.2.2 Match with group 8 failed (internal/external). BGP: TX IPv4 Unicast Grp global 10 Created. BGP: TX IPv4 Unicast Wkr global 10 Cur Blocked (not in list). BGP: TX IPv4 Unicast Wkr global 10 Ref Blocked (not in list). BGP: TX IPv4 Unicast Rpl global 10 1 Created. BGP: TX IPv4 Unicast Rpl global 10 1 Pathext bitfield index 2 allocated. BGP: TX IPv4 Unicast Mem global 10 1 10.7.2.2 Added to group (now has 1 members). BGP: TX IPv4 Unicast Mem global 10 1 10.7.2.2 Staying in WAIT state (current walker waiting for net prepend). BGP: TX IPv4 Unicast Top global Start pathext prepend. BGP: TX IPv4 Unicast Tab Pathext prepend full table refresh. Could it be BGP peer group? Well, I think it has nothing to do with that, unless peers are added to some peer group by default, which is unlikely. It leaves us with the only answer, I think: It is dynamic update group's timer and log output we see. There is more information about this featute here. a new algorithm was introduced that dynamically calculates and optimizes update groups of neighbors that share the same outbound policies and can share the same update messages. No configuration is required to enable the BGP dynamic update group and the algorithm runs automatically. When a change to outbound policy occurs, the router automatically recalculates update group memberships and applies the changes by triggering an outbound soft reset after a 1-minute timer expires.   Inbound policy changes are ignored and still require soft/hard reset. BGP: TX IPv4 Unicast Mem global 10 1 3.3.3.3 Ignoring dummy policy change. BGP: TX IPv4 Unicast Mem global 10 1 10.6.2.2 Ignoring dummy policy change.   ... View more

duplicate   ... View more

@Francesco Molino wrote: The LSDB has to be the same withing the area so you can't filter LSA in this way.   I am not trying to do that. Like at all. I am sorry, if you have been misled by something or misunderstood something in my original post. I thought that the problem is pretty much obvious.  Moreover, I showed examples when filtering works with prefix and access lists. And, for some reason, it does not work with route map. The reason it should work is that it actually has nothing to do with what you written above. And it is in my very first post. It has nothing to do with LSDB consistency, since the routing information is being redistributed from another protocol. And only then the redistributed routes will be sent by ASBR to other OSPF routers to sync LSDB.   P.S.: Just in case I would like to clarify this once more. This is not an inbound route-filtering question.  ... View more

Hello Francesco,   The original post has key words 'out of EIGRP' and 'into OSPF' :). Not vice versa. And the problem is with this particular command   R39(config-router)#distribute-list route-map TEST out eigrp 37 % OUT direction is not allowed in case of OSPF   Thanks for your input anyway.       ... View more