[quagga-users 14854] Re: ospf route-map

On Nov 1, 2017, at 8:34 AM, Mark Coetser <mark-ajVlV48O6s/[email protected]> wrote:
> On 01/11/2017 14:18, Alexis Rosen wrote:
>> On Nov 1, 2017, at 7:59 AM, Mark Coetser <mark-ajVlV48O6s/[email protected]> wrote:
>>> OK i have a working ospf setup between multiple routers including some mikrotiks. OSPF works fine but now I have been trying to create an access list to block a quagga router from advertising a ospf learned subnet and for some reason I cant seem to get this right....
>>> 
>>> so I have router A with a local subnet of 192.168.60.0/24 that is connected to router B which in turn is connected to router C, I am trying to get router B to stop advertising 192.168.60.0/24 to router C
>>> 
>>> Router B quagga config
>>> 
>>> router ospf
>>> redistribute connected route-map RIP_INTF
>>> redistribute rip route-map RIP_INTF
>>> !
>>> ip prefix-list DROPADDR seq 5 deny 192.168.60.0/24
>>> ip prefix-list DROPADDR seq 10 permit any
>>> !
>>> route-map RIP_INTF permit 5
>>> match ip address prefix-list DROPADDR
>>> !
>>> 
>>> with this in place I still see 192.168.60.0/24 distributed to router C
>> What makes you think that that route is in OSPF due to redistribution? If it's the subnet that routers A and B are using to speak OSPF to each other, it's going to be in OSPF even if you don't redistribute it from anywhere.
>> /a
> Hi Alexis
> 
> the 192.168.60.0/24 subnet is the LAN side network of router A, there is a GRE tunnel between router A and router B on a 192.168.170.8/30 subnet.
> 
> router B
> 
> sh ip ospf route
> 
> N IA 192.168.60.0/24       [30] area: 0.0.0.0
>                           via 192.168.170.10, las-gal-fib
> 
> 
> router C
> 
> sh ip ospf route
> 
> N IA 192.168.60.0/24       [40] area: 0.0.0.0
>                           via 172.31.33.252, vlan2

OK, but are you using that interface for OSPF or not? If you are, then the redistribution isn't responsible.

Put another way, if the route goes away when you remove the redistribute statements (and restart ospf), then that looks like a bug. Otherwise not. Dumping the OSPF database entry for that route should also tell you.

/a