On 2012-11-16, Matt Hamilton <[email protected]> wrote: > Hi All, > From what I've read previously I've seen that ospfd will advertise > routes on carp interfaces that are in the BACKUP state. Is this > still the case these days with 5.2? Whilst I'm sure I can do some > magic with ifstated, I just wanted to make sure I'm not solving > something that is already fixed.
Yes, the routes to carp interfaces in BACKUP are advertised but with a low priority (better to have the route stay in the table, even if it goes to a backup firewall, rather than have it drop in and out). > My use-case is that I have a pair of routers that have many vlan > interfaces shared between them via carp for resilience. These routers > then communicate with the rest of the network via ospf. They use > 'redistribute connected' to distribute the subnets on the vlan > interfaces. If an entire router fails then obviously the backup route > is there in OSPF, but if for some reason there is a carp failover for > other reasons and ospfd is still running on the backup router then the > rest of the ospf neighbours don't know to use the route to the backup > carp router (which is now master). Sounds like you're distributing the routes from the carpdev interfaces rather than the carp interfaces so ospfd won't know about the carp state. I think you'll need to stop doing redist connected, list the carp interfaces specifically (using the whole subnet's netmask on the carp interface not just a /32) and not tell ospfd about the carpdevs (vlan interfaces) in order that the carp status is tracked. This works pretty well for me (there is a bug where you need to restart ospfd to add new carp interfaces, but normal operations are fine). Additionally I would suggest using "defer" on your pfsync(4) interfaces in this type of setup.
