Are you or the technicians SURE that this technique is still valid for current world with a lot of virtual servers attached to one switch port? This technique was invented in a time that every switchport was connected to at most one MAC address, so when the switch detects more than one MAC address at a port there was something illegal happening. (or the switchport was connected to a switch)
-----Oorspronkelijk bericht----- Van: Tim Mooney [mailto:[email protected]] Verzonden: vrijdag 6 januari 2017 0:50 Aan: [email protected] Onderwerp: Re: [OpenIndiana-discuss] arp response tuning for IP Source Guard In regard to: Re: [OpenIndiana-discuss] arp response tuning for IP Source...: > On 01/05/17 15:37, Tim Mooney wrote: >> When that was enabled for the subnet I'm on, my hipster workstation >> and the hipster VirtualBox VM I have both started experiencing packet loss. >> Talking with the network engineers, the Cisco switch is sending >> batches of 3 ARP probes periodically, and both my workstation and the >> VM appear to be periodically not responding to the ARP probes. That >> causes the switch to temporarily ban/block packets from either >> system, which is what's causing the intermittent packet loss. >> >> Anyone have any suggestions for what tuning I should be looking at >> that would tell the Illumos network stack that it's OK to respond to >> semi-frequent batches of ARP probes? > > It would be great to see the syslog messages and (if possible) a > packet trace showing what's going on. In general, if the system > itself is directly responsible for these outages, it will at least log > something about the event. At the log level I've been running at, there hasn't been anything useful logged related to this. If necessary, I can definitely dial up the logging. > Are these ARP requests or responses? There are subtle differences > between the two. According to our principal network engineer, the Cisco switch was defaulting to sending 3 ARP probes (in quick succession) every 60 seconds. He has since dialed that back to just 1 per 60 seconds for this particular switch, to see if that had any impact on the issue, but it did not. He's done a bunch more research since I sent my initial question to this list, and right now he thinks the issue may be that the ARP probe from the Cisco switch is unicast, but Solaris apparently may be issuing ARP responses as *broadcast*, which the switch may not be expecting. The reference he found related to broadcast ARP responses is here: http://seclists.org/nmap-dev/2009/q1/176 http://unix.derkeiler.com/Mailing-Lists/SunManagers/2009-01/msg00015.html He's also suggested that I might be able to set 'arp_defend_interval' to something like 20 seconds, so that my workstation just periodically sends unsolicited ARPs for itself, to essentially preempt the switch's probes. Based on the docs he found: http://docs.oracle.com/cd/E36784_01/html/E36845/gnogz.html Since the docs say "Never" in answer to the "When to change" for any of these settings, I haven't actually tried setting arp_defend_interval. The way I read the docs, it seems like arp_publish_interval might be better, but I know better than to argue with our principal network engineer about anything network related. :-) > Based on what I remember from working on this code many years ago, one > of the really confusing bits to deal with is Ethernet bridge > ("switch") behavior itself. Many bridges (I think at least Extreme, > and probably > others) have special mechanisms built-in to protect against ARP > storms, and they rate-limit based on the number of broadcasts. This > is (I > believe!) independent of any sort of "Source Guard" feature. I ran > into this issue numerous times when testing Solaris IP Duplicate > Address Detection. Thanks much for the response! Tim -- Tim Mooney [email protected] Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 _______________________________________________ openindiana-discuss mailing list [email protected] https://openindiana.org/mailman/listinfo/openindiana-discuss _______________________________________________ openindiana-discuss mailing list [email protected] https://openindiana.org/mailman/listinfo/openindiana-discuss
