On 5/24/11 10:12 AM, Philip Homburg wrote:
In your letter dated Tue, 24 May 2011 09:36:15 -0700 you wrote:
One place where is shows up is when you have a stable network where the
routers and hosts have neighbor cache entries for the peers they talk
to. But then there is a short outage on the LAN, e.g., due to a switch
or link failure causing spanning tree to recalculate things. Should
e.g., the router start NUD at that point in time, then NUD is likely to
discard the Neighbor Cache entries before STP is done.
Thus impact of the STP recalculation gets a lot worse, especially if
this is in a massively scaled datacenter.
I'm surprised STP traffic has such a low priority that it is actually affected
by multicast traffic.
That isn't the issue.
During the STP topology change bridges go into blocking state for some
amount of time. This causes packets to be dropped. If this last for more
than 3 seconds, and a NUD probe is started at that point, then the three
*unicast* NS messages that are used for NUD are all dropped.
With current RFC 4861 this means that the NCE has to be discarded, since
the neighbor is deemed UNREACHABLE.
Without the NCE, the next time the node tries to send a packet, it will
end up multicasting NS messages.
Erik
But if that's the case, then I guess that changing the NUD paramters to
something that takes more than 6 seconds would be a good idea.
But that effect can also be obtained by setting the Retrans Timer field in
the RA message to 3000ms or more.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
