Hi Stuart,
I have tried with a carp netmask equal to the physical interface (/24
for example in my lab) and a /32 (like when you have many CARP IP
addresses).
From investigation the problem seems to occur because when a box is the
carp master, their will be a /32 route in the routing table for that
specific IP address (regardless of netmask in hostname.carpX) attached
to the interface 'carpX'.
For example, run 'netstat -rn' on your carp master and you will see
lines like the following;
Internet:
Destination Gateway Flags Refs Use Mtu Prio
Iface
170.16.3/24 170.16.3.1 UG 0 0 - 48
em1
170.16.3.2 08:00:27:a4:02:3d UHLc 0 4 - 4
lo0
170.16.3.3 08:00:27:9f:83:ca UHLc 1 1019447 - L 4
em1
170.16.3.4 170.16.3.4 UH 0 0 - 4
carp1
.2 is this firewall (master), .3 is the other firewall (backup), and .4
is the shared CARP IP.
Because the interface for the .4 IP address is carp1 and not em1 (where
the BGP neighbor is connected), setting the nexthop to .4 fails.
If you run the same on the backup;
Internet:
Destination Gateway Flags Refs Use Mtu Prio
Iface
170.16.3/24 link#2 UC 2 0 - 4
em1
170.16.3.1 c2:00:01:e4:00:00 UHLc 5 143456 - L 4
em1
170.16.3.2 08:00:27:a4:02:3d UHLc 4 158601 - L 4
em1
Notice their is no /32 route for the CARP IP address as it is not the
carp master.
As a result the BGP announcements from the backup firewall do
successfully set the nexthop!
So only the backup firewall can set the nexthop of BGP announcements to
a CARP IP address. The master has those /32 routes which breaks the
nexthop validation check because it thinks the IP you are trying to set
is not in the network directly connected to the neighbor even though it
actually is.
Cheers, Andy.
On Tue 01 Apr 2014 15:03:29 BST, Stuart Henderson wrote:
On 2014-04-01, Andy <a...@brandwatch.com> wrote:
Specifically to accommodate CARP interfaces, to allow setting the
nexthop on an announced route to a CARP IP address?
This currently doesn't work as OpenBGPD considers the CARP interface as
being a different network to the physical interface, even though they
are on the same segment and valid according to the BGP rules of being
directly connected.
What netmasks are you using?
I think perhaps there needs to be some reach-around where a carp has a
/32 or /128, to determine the netmask of the carpdev and use that instead
in some cases...
