Hey all:
My router is apparently sending an ICMP error whenever its sees a packet it decides it either has nothing to do with, or doesn't like. As a result, my network admins disabled my ethernet connection. Anyone run into this sort of a problem before? It's a D-link DI-524. Copied below is an excerpt from their e-mail to me informing me of my disconnection.
Thanks in advance.
In the event the customer wishes for more technical data, here is an example,
showing an IP broadcast packet followed by an erroneous response from the device:
15:25:20.829599 00:03:ba:5d:21:cf > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 43: (tos 0x0, ttl 1, id 1, offset 0, flags [none], proto: UDP (17), length: 29) 140.180.128.152.23918 > 140.180.128.0.31930: UDP, length 1
15:25:20.830460 00:13:46:1e:c6:bb > 00:03:ba:5d:21:cf, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 127, id 13846, offset 0, flags [none], proto: ICMP (1), length: 56) 140.180.138.35 > 140.180.128.152: ICMP time exceeded in-transit, length 36
This is not correct behavior; no device should ever send an ICMP error message
in response to broadcast or multicast traffic. That's because when many devices
behave in this erroneous fashion, it creates very large traffic spikes on the network,
degrading network service for everyone. On large networks, such as many that
compose the campus network, this is a real danger.
(In certain situations, such behavior can even result in self-sustaining
broadcast storms that keep the network unusable.)
This sort of behavior can be caused by a bug in the device's IP stack, requiring a
bug fix from the vendor of the device. (In some unusual situations, it may also be possible
for a device to exhibit this behavior as a result of incorrect configuration, but
this is uncommon.)
(We have seen this pattern before, and it has usually been due to the use
of NAT hardware or NAT software with a defective IP implementation.)
My router is apparently sending an ICMP error whenever its sees a packet it decides it either has nothing to do with, or doesn't like. As a result, my network admins disabled my ethernet connection. Anyone run into this sort of a problem before? It's a D-link DI-524. Copied below is an excerpt from their e-mail to me informing me of my disconnection.
Thanks in advance.
In the event the customer wishes for more technical data, here is an example,
showing an IP broadcast packet followed by an erroneous response from the device:
15:25:20.829599 00:03:ba:5d:21:cf > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 43: (tos 0x0, ttl 1, id 1, offset 0, flags [none], proto: UDP (17), length: 29) 140.180.128.152.23918 > 140.180.128.0.31930: UDP, length 1
15:25:20.830460 00:13:46:1e:c6:bb > 00:03:ba:5d:21:cf, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 127, id 13846, offset 0, flags [none], proto: ICMP (1), length: 56) 140.180.138.35 > 140.180.128.152: ICMP time exceeded in-transit, length 36
This is not correct behavior; no device should ever send an ICMP error message
in response to broadcast or multicast traffic. That's because when many devices
behave in this erroneous fashion, it creates very large traffic spikes on the network,
degrading network service for everyone. On large networks, such as many that
compose the campus network, this is a real danger.
(In certain situations, such behavior can even result in self-sustaining
broadcast storms that keep the network unusable.)
This sort of behavior can be caused by a bug in the device's IP stack, requiring a
bug fix from the vendor of the device. (In some unusual situations, it may also be possible
for a device to exhibit this behavior as a result of incorrect configuration, but
this is uncommon.)
(We have seen this pattern before, and it has usually been due to the use
of NAT hardware or NAT software with a defective IP implementation.)
Facebook
Twitter