08-09-2016 04:08 AM - edited 03-05-2019 04:27 AM
Hi everyone.
I thought this was much simpler than it is turning out to be... I am trying to achieve something that should be quite simple: an AS that originates some routes, and passes some along from other ASes.
For routes originating from this AS, I want to filter them down to a series of aggregates, instead of flooding neighboring ASes with loads of p-t-p and loopback subnets.
This is how Im trying to do it:
router bgp 64606
address-family ipv4
redistribute connected
redistribute static
neighbor 10.45.6.2 route-map TRANSIT-ROUTES-OUT out
network 192.168.0.0
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
exit-address-family
!
ip route 192.168.0.0 255.255.255.0 Null0
ip route 192.168.1.0 255.255.255.0 Null0
ip route 192.168.2.0 255.255.255.0 Null0
ip route 192.168.3.0 255.255.255.0 Null0
!
ip prefix-list AS-ORIG-ROUTES seq 10 permit 192.168.0.0/24
ip prefix-list AS-ORIG-ROUTES seq 20 permit 192.168.1.0/24
ip prefix-list AS-ORIG-ROUTES seq 30 permit 192.168.2.0/24
ip prefix-list AS-ORIG-ROUTES seq 40 permit 192.168.3.0/24
!
route-map TRANSIT-ROUTES-OUT permit 10
match ip address prefix-list AS-ORIG-ROUTES
!
By my reckoning, this should only allow 4x /24 to be advertised from this router (ignoring the transit routes for now) because Im matching an exact mask in my prefix-list.
But when I look in my neighboring AS, I am seeing the following:
AS456#sh ip ro
...
192.168.0.0/24 is variably subnetted, 7 subnets, 4 masks
B 192.168.0.8/32 [20/0] via 10.45.6.3, 00:32:21
B 192.168.0.9/32 [20/0] via 10.45.6.3, 00:32:21
B 192.168.0.10/32 [20/0] via 10.45.6.3, 00:32:21
B 192.168.0.11/32 [20/0] via 10.45.6.3, 00:32:21
B 192.168.0.12/31 [20/0] via 10.45.6.3, 00:32:22
B 192.168.0.0/29 [20/0] via 10.45.6.3, 00:32:22
B 192.168.0.0/24 [20/0] via 10.45.6.3, 00:32:22
...
192.168.1.0/24 is variably subnetted, 4 subnets, 3 masks
...
192.168.2.0/24 is variably subnetted, 8 subnets, 4 masks
...
192.168.3.0/24 is variably subnetted, 5 subnets, 3 masks
...
Basically they very thing I was trying to avoid is happening.
So Im a bit stumped as to why I am seeing longer prefixes coming through when the route-map should be causing everything but some very specific /24's to be filtered out?
So far everything Im reading suggests that this should work, so have I missed something fundamental here?
Thanks!
Tom
08-09-2016 07:42 AM
Small update, becuase maybe this matters, but I think I might have found part of the problem.
In my route map I have 3 clauses:
1. tries to match prefixes with an IPv4 prefix-list
2. tries to match prefixes with an IPv6 prefix-list
3. tries to match prefixes tagged with a certain community
When I remove the second clause, it works as expected. I only see my aggregates and transit routes propagated to other ASes.
What is it about the IPv6 match that is causing this to break so horribly? Should I not be mixing IPv4 and IPv6 in to the same route map, i.e. should I have separate route maps for IPv4 and IPv6 peers?
Thanks
Tom
08-10-2016 01:05 AM
Hi,
I guess it could be the case.
Here is a similar issue described:
https://blog.pierky.com/one-single-route-map-for-both-ipv4-and-ipv6-bgp-prefixes/
Best regards,
Milan
08-10-2016 11:40 AM
Novel solution to make it work with a single route-map.
Having got it working now, I think I will stick to using individual route-maps per address family.
Thanks!
Tom
08-09-2016 03:55 PM
Hello
Try to summarise those routes into an aggregate address and then supress the most specific prefixes.
example:
ip prefix-list AS-ORIG-ROUTES seq 10 permit 192.168.0.0/24
ip prefix-list AS-ORIG-ROUTES seq 20 permit 192.168.1.0/24
ip prefix-list AS-ORIG-ROUTES seq 30 permit 192.168.2.0/24
ip prefix-list AS-ORIG-ROUTES seq 40 permit 192.168.3.0/24
route-map TRANSIT-ROUTES
match ip address prefix-list AS-ORIG-ROUTES
router bgp 64606
address-family ipv4
no neighbor 10.45.6.2 route-map TRANSIT-ROUTES-OUT out
network 192.168.0.0 mask 255.255.252.0
aggregate-address 192.168.0.0 255.255.252.0 as-set suppress-map TRANSIT-ROUTES
res
Paul
08-10-2016 11:34 AM
Hi Paul,
I'll have a look in to this as its not something Ive come across before. But it would seem that mixing IPv4 and IPv6 operations in to the same route-map entry is a no-no in general, and likely what was causing my problem.
I suppose I dont understand why operations for an incompatible address family cant simply be skipped over and only processed when necessary. But it would seem that for an IPv4 peer, an IPv6 specific match rule gets ignored and essentially it ends up creating a route-map entry with no match statement, and a route-map entry with no match statement will apply to anything you pass by it, so in my case it was allowing all of my routes to be advertised.
Since splitting my route-map entries in to IPv4 and IPv6 specific versions, its working as I would expect.
Thanks
Tom
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: