Re: [OpenIndiana-discuss] arp response tuning for IP Source Guard
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:tim.moo...@ndsu.edu]
Verzonden: vrijdag 6 januari 2017 0:50
Aan: openindiana-discuss@openindiana.org
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 tim.moo...@ndsu.edu
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
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
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 tim.moo...@ndsu.edu
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
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] arp response tuning for IP Source Guard
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.
Are these ARP requests or responses? There are subtle differences
between the two.
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.
It's also possible that it's something else -- such as a driver issue.
--
James Carlson 42.703N 71.076W
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] arp response tuning for IP Source Guard
All- I'm running hipster, updated a few days ago, illumos-b106467 Our network engineers recently enabled Cisco's IP Source Guard on the subnet my workstation is on. The IP Source Guard overview is here: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SY/configuration/guide/sy_swcg/ip_source_guard.html#66969 It's basically a bit of additional network protection to help prevent man-in-the-middle attacks via arp spoofing. 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? Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu 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 openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] OpenIndiana upgrade
I also fiddling around his problem for a while. It seems that the problem correlates with some obsoleted packages and locked version in the incorporations e.g. ips-incorporation is obsoleted now. There I stumble in the incorporation package manifests over the dependency type 'incorporate'. I can't unlock this depend versions, right? That has nothing to do with facet.version-lock? On 31.12.16 18:51, Hans J Albertsson wrote: > > The message I answered was Russel's last, not Mr Coopersmith's. > I'm on a phone with limited intelligence... > Hans J. Albertsson > From my Nexus 5 > > Den 31 dec. 2016 18:49 skrev "Hans J Albertsson" < > hans.j.alberts...@gmail.com>: > > > I had the same kind of problem with 151a7, no f...n way to make updates > > run OK. > > > > The messages appearing for you seem a lot like what I had. > > > > My best guess is that this is a basic flaw in logic, that in most cases > > would never cause a problem, but somehow, in a personal-computer use of OI, > > doesn't keep enough info around to step past some unexpected hurdle. > > > > Hans J. Albertsson > > From my Nexus 5 > > > > Den 31 dec. 2016 18:01 skrev "Alan Coopersmith" < > > alan.coopersm...@oracle.com>: > > > >> On 12/31/16 05:00 AM, russell wrote: > >> > >>> Hi Alex, > >>> > >>> I tried a pkg image-update -v --be-name openindiana-hipster-NN this > >>> morning > >>> which did actually complete okay with information about gnu/tar. > >>> > >>> After booting from the new environment and then attempting a pkg update > >>> -be-name > >>> openindiana-hipster-NN+1 I obtained the following message > >>> > >> > >> BTW, you know that "pkg update" and "pkg image-update" do the same thing, > >> right? > >> The original name was image-update and when it was shortened to update, > >> the old > >> name was left in IPS as a compatibility alias. > >> > >> -alan- > >> > >> > >> ___ > >> openindiana-discuss mailing list > >> openindiana-discuss@openindiana.org > >> https://openindiana.org/mailman/listinfo/openindiana-discuss > >> > > > ___ > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > https://openindiana.org/mailman/listinfo/openindiana-discuss > ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
