Subject: Your "favorite" network faults

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 10 Apr 2009 12:48:52 -0400

As part of a research project, we are working on automated diagnostics  
of network-related faults in residential, SOHO, conference/special  
event, hotel and similar networks. If you have observed errors that  
were hard for a lay person to diagnose, whether due to end system  
problems, NATs, LAN or Internet issues, please send me a brief  
description. (Also, contacts in tech support for such environments  
would be most helpful, particularly if they might be willing to talk  
to us.)

Henning

---

From: Mark Andrews <[email-masked]>
Date: Sat, 11 Apr 2009 08:08:31 +1000

In message <[email-masked]>, Henning Schu
lzrinne writes:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

1.
	Hotel's implementing "transparent" DNS caching which was not
	transparent.  This breaks any iterative resolvers sitting
	behinde the "transparent" DNS cache as they are expecting
	authoritative answers and the answers from the cache are
	non-authoritative.  Iterative resolvers will become more
	common as people turn on DNSSEC validation and need a
	DNSSEC aware path and the easiest way to do that is to
	be a iterative resolver.

	While I can understand interception of DNS queries prior
	to signing on there is no justification in continuing to
	intercept the queries after signing on especially queries
	with RD=0 as the answers will not be accepted.

2.
	DHCP offers not being accepted due to the offer have a ttl of
	1.  Fault in the router.

	Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 10 Apr 2009 13:11:29 -0400

Ethernet duplex mismatch has to be the most common (if your fast  
Ethernet doesn't seem to be able to push more than 5-10 Mbps, suspect  
this). See Stanislav's writeup :
http://shlang.com/writing/tcp-perf.html

My personal favorite is re-use of MAC addresses on an Ethernet. (There  
once was a switch vendor who used the same MAC address for an entire set
of machines. Worked fine unless you had two on the same LAN.) That is  
very hard to diagnose IMO, but not common.

And, in the multicast world, there are the actions (or lack thereof)  
of IGMP snooping switches. That can cause a wide variety of weirdness.

On Apr 10, 2009, at 12:48 PM, Henning Schulzrinne wrote:

> As part of a research project, we are working on automated  
> diagnostics of network-related faults in residential, SOHO,  
> conference/special event, hotel and similar networks. If you have  
> observed errors that were hard for a lay person to diagnose, whether  
> due to end system problems, NATs, LAN or Internet issues, please  
> send me a brief description. (Also, contacts in tech support for  
> such environments would be most helpful, particularly if they might  
> be willing to talk to us.)
>
> Henning

Regards
Marshall

---

From: David Morris <[email-masked]>
Date: Sun, 12 Apr 2009 17:47:11 -0700 (PDT)

Shot myself in the foot recently when I reconfigured my local LAN from /25 
to /24 and forgot I still had the old ISDN router plugged in which routed 
to the other 1/2 of the /25. Caused a lot of flakeyness which I really 
didn't figure out until I ran Ethereal and saw the ISDN manufacturer 
annotated in its MAC address.

Can't speculate about lay persons since I tend to think my network is more 
complex than they would start with.

David Morris

On Fri, 10 Apr 2009, Henning Schulzrinne wrote:

> As part of a research project, we are working on automated diagnostics of 
> network-related faults in residential, SOHO, conference/special event, hotel 
> and similar networks. If you have observed errors that were hard for a lay 
> person to diagnose, whether due to end system problems, NATs, LAN or Internet 
> issues, please send me a brief description. (Also, contacts in tech support 
> for such environments would be most helpful, particularly if they might be 
> willing to talk to us.)
>
> Henning

---

From: Ole Jacobsen <[email-masked]>
Date: Sun, 12 Apr 2009 18:49:55 -0700 (PDT)

OK, I'll chime in: I got one of those key-chain sized Ethernet 
loopback connectors. The idea is that you attach one end to a patch 
cable and the other to the hub and if all is well the link light goes 
on on the hub. So, I am sitting there admiring this wonder when all my 
telnet sessions (OK, maybe SSH sessions) go away, webpages won't load 
and AIM/Jabber disconnects. Of course the loopback device is causing a 
broadcast storm and the hub isn't working well.

This supposedly does not happen on a switch... I haven't bothered to 
try.

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: [email-masked]  URL: http://www.cisco.com/ipj

---

From: Ofer Inbar <[email-masked]>
Date: Mon, 13 Apr 2009 11:10:05 -0400

>send me a brief description. (Also, contacts in tech support for  

I'm not sure if this is the kind of fault you're looking for.  In
residential networks, often the DSL or Cable "modem" has a misfeature
that caches the MAC address of the first device it sees, and won't
talk to any others.  Often it will only forget the cached MAC address
if it's been powered off for a significant time (15 minutes, or an hour).

When the ISP's tech sets up a new home, sometimes they come with
Windows based software.  If the customer doesn't use Windows, the tech
will connect their own laptop to run the setup software.  Or, the ISP
person wants to connect directly rather than through the wireless
router.  Then the customer tries to use it and it doesn't work, but
since the ISP's tech had no problems and reported the Internet
connection working, they blame the customer's computer or wireless
router.

In my experience, I've found that ISP setup people rarely know about
this, and often don't understand what "caching the MAC address" means
even if you try to explain it to them, to ask if their equipment does
it.  I think a lot of customers who experience this never figure it
out before the problem mysteriously disappears eventually, when they
happen to have the thing powered off for a while because they thought
it wasn't working.

I've also encountered this at other people's homes, where they don't
have wireless, and one person's computer gets Internet but the other's
doesn't most of the times they try - I've "solved" this problem for
other people several times, merely by explaining that they have to
power off the dsl/cable box for a certain number of minutes when
switching computers (they can figure out how long by experimenting),
or by connecting one laptop and sharing its connection to the other
via wireless.
  -- Cos

---

From: Lars Eggert <[email-masked]>
Date: Tue, 14 Apr 2009 15:15:45 +0300

Daisy-chaining a small number of hubs also causes interesting issues.  
Doesn't happen much anymore, now that switches have become prevalent.

---

From: "TJ" <[email-masked]>
Date: Tue, 14 Apr 2009 10:30:20 -0400

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lars
>Eggert
>Sent: Tuesday, April 14, 2009 8:16 AM
>To: Ole Jacobsen
>Cc: IETF discussion list
>Subject: Re: Your "favorite" network faults
>

Exactly, was replaced with daisy-chaining large numbers of switches (where
large == "more than 7 or so")
:)

>> This supposedly does not happen on a switch... I haven't bothered to

Actually, I am not sure a switch would be immune ... broadcast (and
multicast, sans snooping) still gets flooded ...
(IIRC it also triggers bpdu-guard to disable the ports, if the config is
just right (or just wrong)).

/TJ

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 15 Apr 2009 08:43:14 -0600

A NAT that if it's external IP was 1.2.3.4, any time it saw the binary  
pattern 0x01020304 passing through it in any data it would replace it  
with the nats internal IP. (Many NATS call this "feature" a "Generic  
ALG" so if you see a NAT with that, run screaming) Most stuff worked  
fine but the bug was found when someone was downloading the ISO image  
for a Linux CD that just happened to contain the external IP in some  
executable that got changed in the download. Credit to Adam Roach for  
figuring out what was going on.