Re: openbgpd "depend on"
Hello Stuart, I see not that I have not been entirely clear on my setup. Traditionally I used carp on both upstream interfaces (to have a common nexthop address in BGP routing) and also on my downstream interfaces (to have a floating default gateway for my hosts). As it stands now I cannot use a carp nexthop on my upstreams, so a solution would be to have upstream BGP peering alter its meds or as-path depending on downstream carp interface state. This way I can retain symmetric routing while not setting an upstream carp nexthop address. On Fri, Jun 11, 2021 at 10:23 PM Stuart Henderson wrote: > On 2021-06-11, open...@kene.nu wrote: > > Hello Stuart, > > > > I do set the carp address as nexthop. This works in a "traditional" L2 > > environment as expected. However, to make a long story short, in a vxlan > > environment L2 redundancy protocols like carp that rely on gARP do not > work > > as expected. > > > > So I need to have the backup firewall tell the router in some other way > > (bgp wise) that the path via it is worse compared with the master. The > > suggestion offered by Claudio would be spot on for my use case. I would > > argue others would benefit from this too as I am running a fairly > standard > > symmetric vxlan routing clos setup. > > I'm not quite sure I get what you're trying to do then - so instead of > using something which needs carp to work, you want to use something else > which also needs carp to work? > > >
Re: openbgpd "depend on"
On 2021-06-11, open...@kene.nu wrote: > Hello Stuart, > > I do set the carp address as nexthop. This works in a "traditional" L2 > environment as expected. However, to make a long story short, in a vxlan > environment L2 redundancy protocols like carp that rely on gARP do not work > as expected. > > So I need to have the backup firewall tell the router in some other way > (bgp wise) that the path via it is worse compared with the master. The > suggestion offered by Claudio would be spot on for my use case. I would > argue others would benefit from this too as I am running a fairly standard > symmetric vxlan routing clos setup. I'm not quite sure I get what you're trying to do then - so instead of using something which needs carp to work, you want to use something else which also needs carp to work?
Re: openbgpd "depend on"
Hello Stuart, I do set the carp address as nexthop. This works in a "traditional" L2 environment as expected. However, to make a long story short, in a vxlan environment L2 redundancy protocols like carp that rely on gARP do not work as expected. So I need to have the backup firewall tell the router in some other way (bgp wise) that the path via it is worse compared with the master. The suggestion offered by Claudio would be spot on for my use case. I would argue others would benefit from this too as I am running a fairly standard symmetric vxlan routing clos setup. On Thu, Jun 10, 2021 at 7:48 PM Stuart Henderson wrote: > On 2021-06-10, open...@kene.nu wrote: > > Looks like the syntax is not valid and I cannot find any reference in the > > man pages either. Maybe am missing the intent of your reply. Is it > intended > > as pseudo code that would pose as my intent or is it actually already > > possible to achieve this? > > It's not yet implemented. > > I didn't quite work out from your description what you'd like openbgpd > to do, but are you aware that you don't have to distribute a route which > points at "this router's IP address"? Some situations involving carp > routes can be dealt with by setting the nexthop as the carp address, > e.g. "network 192.0.2.0/29 set nexthop 10.100.2.1" Not sure if this > helps you but maybe. > > >
Re: openbgpd "depend on"
On 2021-06-10, open...@kene.nu wrote: > Looks like the syntax is not valid and I cannot find any reference in the > man pages either. Maybe am missing the intent of your reply. Is it intended > as pseudo code that would pose as my intent or is it actually already > possible to achieve this? It's not yet implemented. I didn't quite work out from your description what you'd like openbgpd to do, but are you aware that you don't have to distribute a route which points at "this router's IP address"? Some situations involving carp routes can be dealt with by setting the nexthop as the carp address, e.g. "network 192.0.2.0/29 set nexthop 10.100.2.1" Not sure if this helps you but maybe.
Re: openbgpd "depend on"
Looks like the syntax is not valid and I cannot find any reference in the man pages either. Maybe am missing the intent of your reply. Is it intended as pseudo code that would pose as my intent or is it actually already possible to achieve this? # bgpd -vn /etc/bgpd.conf:47: syntax error # awk 'NR==47' /etc/bgpd.conf match to group "leaf" depend on carp100 prepend-self 5 # uname -a OpenBSD fw1 6.8 GENERIC.MP#2 amd64 # ifconfig carp100 | grep carp: carp: MASTER carpdev vlan100 vhid 1 advbase 1 advskew 10 On Thu, Jun 10, 2021 at 2:10 PM wrote: > This looks precisely what I am looking for. Will try it out. Thank you! > > On Wed, Jun 9, 2021 at 10:42 AM Claudio Jeker > wrote: > >> On Wed, Jun 09, 2021 at 09:57:32AM +0200, open...@kene.nu wrote: >> > Hello, >> > >> > Just a question and maybe a suggestion. I am implementing a few DCs that >> > use vxlan symmetric routing and hence, layer2 redundancy protocols like >> > CARP (and VRRP/HSRP) do not work as intended due to evpn layer2 being >> the >> > technology of choice to announce ARP entries. >> > >> > This led me to try out the "depend on carp" functionality that is >> available >> > on openbgpd. It does what I want, partially. It would be much more >> usable >> > if you cold define what this functionality does in case of a CARP backup >> > state. Currently it puts the bgp neighbor into Idle state. However, it >> > would be better if one could define that it should as-path prepend >> and/or >> > add a metric (MED) instead. This way, carp failovers would not rely on >> the >> > tedious and relatively time consuming process of setting up a BGP >> session >> > and announcing prefixes before it can truly be carp master. >> > >> > WDYT? >> >> The 'depend on' feature was added to use a CARP cluster as a BGP border >> router (e.g. at an IXP that only gives one IP/port). In that case the >> backup carp interface is not able to open a TCP session. The backup carp >> interface is not reachable and the session would conflict with the master >> session. >> >> What you would like is to add depend on on announcements (network >> 10.0.0.0/24 depend on carp0) or probably as a filter (match to group >> uplinks depend on carp set med 100). At least this is how I understand >> your request. >> >> -- >> :wq Claudio >> >>
Re: openbgpd "depend on"
This looks precisely what I am looking for. Will try it out. Thank you! On Wed, Jun 9, 2021 at 10:42 AM Claudio Jeker wrote: > On Wed, Jun 09, 2021 at 09:57:32AM +0200, open...@kene.nu wrote: > > Hello, > > > > Just a question and maybe a suggestion. I am implementing a few DCs that > > use vxlan symmetric routing and hence, layer2 redundancy protocols like > > CARP (and VRRP/HSRP) do not work as intended due to evpn layer2 being the > > technology of choice to announce ARP entries. > > > > This led me to try out the "depend on carp" functionality that is > available > > on openbgpd. It does what I want, partially. It would be much more usable > > if you cold define what this functionality does in case of a CARP backup > > state. Currently it puts the bgp neighbor into Idle state. However, it > > would be better if one could define that it should as-path prepend and/or > > add a metric (MED) instead. This way, carp failovers would not rely on > the > > tedious and relatively time consuming process of setting up a BGP session > > and announcing prefixes before it can truly be carp master. > > > > WDYT? > > The 'depend on' feature was added to use a CARP cluster as a BGP border > router (e.g. at an IXP that only gives one IP/port). In that case the > backup carp interface is not able to open a TCP session. The backup carp > interface is not reachable and the session would conflict with the master > session. > > What you would like is to add depend on on announcements (network > 10.0.0.0/24 depend on carp0) or probably as a filter (match to group > uplinks depend on carp set med 100). At least this is how I understand > your request. > > -- > :wq Claudio > >
Re: openbgpd "depend on"
On Wed, Jun 09, 2021 at 09:57:32AM +0200, open...@kene.nu wrote: > Hello, > > Just a question and maybe a suggestion. I am implementing a few DCs that > use vxlan symmetric routing and hence, layer2 redundancy protocols like > CARP (and VRRP/HSRP) do not work as intended due to evpn layer2 being the > technology of choice to announce ARP entries. > > This led me to try out the "depend on carp" functionality that is available > on openbgpd. It does what I want, partially. It would be much more usable > if you cold define what this functionality does in case of a CARP backup > state. Currently it puts the bgp neighbor into Idle state. However, it > would be better if one could define that it should as-path prepend and/or > add a metric (MED) instead. This way, carp failovers would not rely on the > tedious and relatively time consuming process of setting up a BGP session > and announcing prefixes before it can truly be carp master. > > WDYT? The 'depend on' feature was added to use a CARP cluster as a BGP border router (e.g. at an IXP that only gives one IP/port). In that case the backup carp interface is not able to open a TCP session. The backup carp interface is not reachable and the session would conflict with the master session. What you would like is to add depend on on announcements (network 10.0.0.0/24 depend on carp0) or probably as a filter (match to group uplinks depend on carp set med 100). At least this is how I understand your request. -- :wq Claudio
openbgpd "depend on"
Hello, Just a question and maybe a suggestion. I am implementing a few DCs that use vxlan symmetric routing and hence, layer2 redundancy protocols like CARP (and VRRP/HSRP) do not work as intended due to evpn layer2 being the technology of choice to announce ARP entries. This led me to try out the "depend on carp" functionality that is available on openbgpd. It does what I want, partially. It would be much more usable if you cold define what this functionality does in case of a CARP backup state. Currently it puts the bgp neighbor into Idle state. However, it would be better if one could define that it should as-path prepend and/or add a metric (MED) instead. This way, carp failovers would not rely on the tedious and relatively time consuming process of setting up a BGP session and announcing prefixes before it can truly be carp master. WDYT?
