bonding: send IPv6 neighbor advertisement on failover

I don't see any way to address David Steven's comment since there is currently no NA tunable in the IPv6 code.

Quoted 1 line

I don't see any way to address David Steven's comment since there is currently no NA tunable in the IPv6 code.

Brian,
How do you feel about doubling up with dad_transmits for that
part?

At least the switch/cache updating portion is the same
in both cases.

I don't really want to since this is bonding-specific behavior, and we're not performing DAD for the address. This is just another sysfs
entry: /sys/class/net/bond*/bonding/num_unsol_na, not a sysctl.

Brian Haley <[email protected]> wrote on 10/10/2008 07:34:58 AM:

Quoted 3 lines

I don't really want to since this is bonding-specific behavior, and we're not performing DAD for the address. This is just another sysfs
entry: /sys/class/net/bond*/bonding/num_unsol_na, not a sysctl.

I think they really are the same case, and doing DAD
would solve the problem just as well. But I can hold my nose a little bit and live with it. :-) Getting the problem solved is more important than the details.

As a semi-related question, what does IPv6 do if it receives a
gratutitous NA, and finds a duplicate?

I agree that doing DAD would update the switches, peers, etc,
but, if I'm reading the IPv6 code correctly, the delay between probes is one second (nd_tbl.retrans_time), and it looks like there's an initial delay of up to 1 second as well (in addrconf_dad_kick, the rtr_solicit_delay). For failover purposes, we want to issue the gratuitous ARP or NA packets immediately with a minimal delay between probes.

Quoted 2 lines · Jay Vosburgh

As a semi-related question, what does IPv6 do if it receives a
gratutitous NA, and finds a duplicate?

If a node has an IPv6 neighbor entry and receives an unsolicited NA it will change it's state to stale, forcing a re-lookup on the next transmit. An un-solicited NA will change the state to reachable.

Quoted 8 lines

I agree that doing DAD would update the switches, peers, etc,
but, if I'm reading the IPv6 code correctly, the delay between probes is one second (nd_tbl.retrans_time), and it looks like there's an initial delay of up to 1 second as well (in addrconf_dad_kick, the rtr_solicit_delay). For failover purposes, we want to issue the gratuitous ARP or NA packets immediately with a minimal delay between probes.

Right, and since a bond failover event should be rare, I think sending the NA immediately is OK. All those random delays are meant to cover the case, for example, when a router sends an advertisement with a new prefix - you don't want everyone that receives it to do DAD immediately since it could overwhelm the network.

-Brian

Signature · 3 lines

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 3 lines · Brian Haley

Quoted 2 lines · Jay Vosburgh

As a semi-related question, what does IPv6 do if it receives a
gratutitous NA, and finds a duplicate?

Quoted 4 lines

If a node has an IPv6 neighbor entry and receives an unsolicited NA it will change it's state to stale, forcing a re-lookup on the next transmit. An un-solicited NA will change the state to reachable.

                ^^^^^^^^^^^^

You probably meant to say "solicited". Unsolicited NAs can only change the state to STALE.

Also, the re-lookup will happen on a delay after the transmit.

-vlad

Quoted 4 lines · Vlad Yasevich

Quoted 3 lines · Brian Haley

Quoted 2 lines · Jay Vosburgh

As a semi-related question, what does IPv6 do if it receives a
gratutitous NA, and finds a duplicate?

I think Jay was asking about the case where the target address in the NA matches the address of the receiving interface. The RFCs don't describe how to handle such a case and leave it to the implementation. Linux logs a warning message and ignores such NA.

Thanks
Sridhar

Quoted 11 lines

Quoted 3 lines

If a node has an IPv6 neighbor entry and receives an unsolicited NA it will change it's state to stale, forcing a re-lookup on the next transmit. An un-solicited NA will change the state to reachable.

                ^^^^^^^^^^^^

You probably meant to say "solicited". Unsolicited NAs can only change the state to STALE.

Also, the re-lookup will happen on a delay after the transmit.

-vlad

Updated to address Vlad's comment about storing the link-local IPv6 address in the bond/vlan structure, I no longer overwrite the existing address with a newer one. Also added missed locking for the inet6_dev.

I don't see any way to address David Steven's comment since there is currently no NA tunable in the IPv6 code.

---

This patch adds better IPv6 failover support for bonding devices, especially when in active-backup mode and there are only IPv6 addresses configured, as reported by Alex Sidorenko.

- Creates a new file, net/drivers/bonding/bond_ipv6.c, for the IPv6-specific routines. Both regular bonds and VLANs over bonds are supported.

- Adds a new tunable, num_unsol_na, to limit the number of unsolicited IPv6 Neighbor Advertisements that are sent on a failover event. Default is 1.

- Creates two new IPv6 neighbor discovery functions:

ndisc_build_skb()
ndisc_send_skb()

These were required to support VLANs since we have to be able to add the VLAN id to the skb since ndisc_send_na() and friends shouldn't be asked to do this. These two routines are basically __ndisc_send() split into two pieces, in a slightly different order.

- Updates Documentation/networking/bonding.txt and bumps the rev of bond support to 3.4.0.

On failover, this new code will generate one packet:

- An unsolicited IPv6 Neighbor Advertisement, which helps the switch learn that the address has moved to the new slave.

Testing has shown that sending just the NA results in pretty good behavior when in active-back mode, I saw no lost ping packets for example.

-Brian

Signed-off-by Brian Haley <[email protected]>

---

Updated to address Vlad's comment about storing the link-local IPv6 address in the bond/vlan structure, I no longer overwrite the existing address with a newer one. Also added missed locking for the inet6_dev.

I don't see any way to address David Steven's comment since there is currently no NA tunable in the IPv6 code.

---

This patch adds better IPv6 failover support for bonding devices, especially when in active-backup mode and there are only IPv6 addresses configured, as reported by Alex Sidorenko.

- Creates a new file, net/drivers/bonding/bond_ipv6.c, for the IPv6-specific routines. Both regular bonds and VLANs over bonds are supported.

- Adds a new tunable, num_unsol_na, to limit the number of unsolicited IPv6 Neighbor Advertisements that are sent on a failover event. Default is 1.

- Creates two new IPv6 neighbor discovery functions:

ndisc_build_skb()
ndisc_send_skb()

These were required to support VLANs since we have to be able to add the VLAN id to the skb since ndisc_send_na() and friends shouldn't be asked to do this. These two routines are basically __ndisc_send() split into two pieces, in a slightly different order.

- Updates Documentation/networking/bonding.txt and bumps the rev of bond support to 3.4.0.

On failover, this new code will generate one packet:

- An unsolicited IPv6 Neighbor Advertisement, which helps the switch learn that the address has moved to the new slave.

Testing has shown that sending just the NA results in pretty good behavior when in active-back mode, I saw no lost ping packets for example.

-Brian

Signed-off-by Brian Haley <[email protected]>

---

Hi Jay,

Did you ever get a chance to look at this patch? Now that net-next is open I'd like to resubmit it.

Thanks,

-Brian

Quoted 39 lines · Brian Haley

Updated to address Vlad's comment about storing the link-local IPv6 address in the bond/vlan structure, I no longer overwrite the existing address with a newer one. Also added missed locking for the inet6_dev.

I don't see any way to address David Steven's comment since there is currently no NA tunable in the IPv6 code.

---

This patch adds better IPv6 failover support for bonding devices, especially when in active-backup mode and there are only IPv6 addresses configured, as reported by Alex Sidorenko.

- Creates a new file, net/drivers/bonding/bond_ipv6.c, for the IPv6-specific routines. Both regular bonds and VLANs over bonds are supported.

- Adds a new tunable, num_unsol_na, to limit the number of unsolicited IPv6 Neighbor Advertisements that are sent on a failover event. Default is 1.

- Creates two new IPv6 neighbor discovery functions:

ndisc_build_skb()
ndisc_send_skb()

These were required to support VLANs since we have to be able to add the VLAN id to the skb since ndisc_send_na() and friends shouldn't be asked to do this. These two routines are basically __ndisc_send() split into two pieces, in a slightly different order.

- Updates Documentation/networking/bonding.txt and bumps the rev of bond support to 3.4.0.

On failover, this new code will generate one packet:

- An unsolicited IPv6 Neighbor Advertisement, which helps the switch learn that the address has moved to the new slave.

Quoted 8 lines

Testing has shown that sending just the NA results in pretty good behavior when in active-back mode, I saw no lost ping packets for example.

-Brian

Signed-off-by Brian Haley <[email protected]>

---

--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html