cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
281
Views
0
Helpful
3
Replies

Redistribute BGP into OPSP with routemap

switched switch
Level 1
Level 1

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?

1 Accepted Solution

Accepted Solutions

Rolf Fischer
Level 9
Level 9

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

View solution in original post

3 Replies 3

Rolf Fischer
Level 9
Level 9

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

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

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.

Review Cisco Networking for a $25 gift card