Monitoring of Internet connection

[Ben Scott]

On 6/7/07, VirginSnow at vfemail.net <VirginSnow at vfemail.net> wrote:
> Do you know if there's a switch between your gateway and the next
> router?

  My gateway has an Ethernet interface connected to a repeater.  The
repeater was recently added for sniffing purposes.  I've also got a
laptop running a passive-only sniffer plugged into the repeater.  The
only other thing connected to the repeater is the Ethernet interface
on the local radio transceiver.  That's connected to an antenna on the
roof, which transmits to a tower on a hill a mile or so away.  From
there, it's the ISP's gear.  I assume the ISP gear consists of some
kind of super-duper Wireless Access Point connected to some
combination of routers, switches, DSUs and other ISPish stuff.

  The ISP has said there's a router at the tower base.  The ISP has
also said that the radio gear has MAC address management.  In
particular, that if I change the MAC address of my gateway, I have to
power cycle our radio, because it will only allow one MAC from the
Ethernet side out into the radio net.

  I'm generally inclined to trust this particular ISP, but they could
of course be incorrect for any number of reasons (their
misunderstanding, vendor misinformation, misconfigured equipment,
failing unit, lying vendor, or even a just plain lying ISP).

> Maybe someone on your WAN decided to use the same MAC as your
> gateway, and you only see problems when they turn on their equipment
> and sit there scratching their head.

  Hmmm.  I hadn't thought about duplicate MAC addresses.  I'll have to
keep that in mind as I monitor things.  (Everything's working fine
right now.  <crosses fingers>)

> Are you getting *all* the TCP/UDP responses you should, or just a portion of them?
> (I'd suspect the latter.)

  Well, I'm not really seeing any TCP/UDP *responses* at all.  :)
Since our gateway doesn't have an ARP entry for the ISP gateway, it is
unable to send anything at or above the IP layer.

  When the trouble occurs, I've seen:

(1) ARP queries from my gateway, for the ISP gateway, out to the radio
(2) Other IP packets (TCP, UDP, occasional ICMP) in from the ISP

  The TCP and UDP packets appear to be connection attempts from the
rest of the world.  For example, TCP SYN packets to port 25, or UDP
packets from VPN clients.  This would be consistent with the ISP
gateway having an ARP entry for my gateway, but me not having an ARP
entry for the ISP.

> Remember ARP requests/responses can also be lost due to collisions.

  Hmmmm.

  The Ethernet interface on the local radio is only half-duplex, but
there's only my gateway and it (and the sniffer, but that doesn't
transmit).  I have not seen the collision indicator on the repeater
light up yet.  It's also been working fine for years.  So I don't
think collisions are a problem there.

  Now, I don't know much about how the radio+Ethernet combination
works at the media or data link layers.  I'm not sure if or how
collisions exist on the radio net.  (It could be a
multiplexing/multi-frequency system, for all I know.)  Worth looking
into.  I'll ask the ISP.

> Have you tried decreasing your ARP reply timeout?

  *Decreasing* it?  :)  I see ARP queries from my gateway once per
second when the trouble happens.  It's never getting a response.

  What I haven't tried yet -- this is next on my list -- is assigning
a static ARP entry for the ISP gateway's last known MAC address, if
and when the problem happens again.  That might at least give me the
ability to use "ping" as a diagnostic tool.

> It might also help to know what OS the peer router is running.  Have you
> nmapped it yet?

  The ISP has said it's a Cisco.  I haven't run any mapping tools.
Worth a shot.  I'll give that a try tonight after hours.

  The local radio says "Alvarion" and "BreezeACCESS" on the label.  I
have found the vendor website, but they've got a bunch of products,
and I dunno what we've got.  :)

  Thanks for your response.  You've given me some good food for thought.

  -- Ben