07-02-2016 06:30 PM - edited 03-05-2019 04:21 AM
Hi All,
I am doing some testing with some BGP prefixes that we I am injecting into our OSPF domain. For the purpose of discussion we take full views at the border so we need to ensure there is no accidental leakage of all BGP routes into OSPF. .
router ospf 1
redistribute bgp 11111 subnets route-map BGPintoOSPF
ip prefix-list CUST1 seq 5 permit 77.77.76.0/24
!
ip prefix-list CUST2 seq 10 permit 77.77.77.0/24
!
route-map BGPintoOSPF permit 10
match ip address prefix-list CUST1
!
route-map BGPintoOSPF permit 20
match ip address prefix-list CUST2
!
The problem I have, is it is working well for the route-map permit 10 statement. But if I start to create another routemap permit 20 statement, before I have a chance to put in " match ip address prefix-list CUST2" I have ALL BGP routes in OSPF as it thinks to permit everything!!!
Is this normal and expected?
Is there any solution here? I am trying to find a way to break CUST1 and CUST2 into two separate prefix lists for identification and troubleshooting?
Solved! Go to Solution.
07-03-2016 01:54 AM
Hello,
my quick gns3 testing showes the same behavior and I think this is expected (but I wasn't really aware of it so far).
A new route-map permit statement without a match clause is an implicit "permit all".
In order to avoid this behavior, you could first add a new "deny 15" statement, add the "permit 20" and the match clause without any hurry, and finally remove the "deny 15" statement. Quite cumbersome, I know...
I think in most cases it should be sufficient to prepare the new permit statement completely in an editor and then paste it into the running-config.
HTH
Rolf
07-03-2016 01:54 AM
Hello,
my quick gns3 testing showes the same behavior and I think this is expected (but I wasn't really aware of it so far).
A new route-map permit statement without a match clause is an implicit "permit all".
In order to avoid this behavior, you could first add a new "deny 15" statement, add the "permit 20" and the match clause without any hurry, and finally remove the "deny 15" statement. Quite cumbersome, I know...
I think in most cases it should be sufficient to prepare the new permit statement completely in an editor and then paste it into the running-config.
HTH
Rolf
07-03-2016 06:03 AM
Thanks Rolf,
I believe it is also expected, one of those 'gotcha's' I guess. What I was thinking maybe that it only was applied after moving out from the route-map configuration but I guess not - glad I didn't do this on a live network!
I assume the deny before the permit would work OK, I'll test this now to confirm
07-03-2016 06:15 AM
Yep, by having the deny after the first permit, and then adding another permit after that deny doesnt inject them under the new permit.. Then we remove the deny to have them injected.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide