WAN traffic logs needed

[Nullity]

Well, probably irrelevant anyway. Can't even remember the last time I saw a hub : -)

Dieter wanted to load wireshark onto a PC and view the traffic between his router's WAN port and the modem.

Full duplex uses one pair to send and a different pair to receive on. Half uses a single pair for both send and receive. Since hubs support half duplex only I was just speculating whether a hub would, or would not work, as a tap but,

1. He'd be hard pressed to find a hub.
2. I do not know if newer devices even bother to negotiate full or half duplex anymore.
3. He'd be effectively reducing WAN speed (even further).

But yes, wireshark would reset his PC port to promiscuous.

I will admit not understanding duplex types, and a quick search of my Cisco book says you are right about hubs being half-duplex and switches being full-duplex.

I think you may be confusing the fact that duplex type does not imply hub or switch, but apparently a hub & switch does imply half-duplex & full-duplex, respectively.

 

[Klueless]

Hubs, by definition, are half duplex. Most anything else can downgrade themselves to talk to a hub. A hub can not upgrade itself. Because hubs pretty much went extinct over a decade ago I have no idea if modern devices will even bother to negotiate down to half duplex. Even if they did his WAN speed would be cut.

I only brought up the hub concept to illustrate why connecting his WAN and sniffer into a switch wouldn't allow him to view traffic (even in promiscuous mode) unless his switch could be spanned or mirrored.

(I failed , it was a bad analogy, no one else is old enough to remember hubs : -)

 

[RMerlin]

A managed switch with port mirroring remains the best solution. Something like the Netgear GS108T smart switch for instance - I got mine for under 80$ CAD a few months ago.

 

[dieter]

Thank you RMerlin. I think the GS108t will do the trick. $62 at Newegg. Not bad.
Did not know that switches could be managed. Better read the manual...

 

[dieter]

I talked to Netgear re the GS108t and the tech person said that this switch can will not replicate the router WAN port to another switch port. You can specify a LAN source and LAN destination port. She suggested their FVS318N router which supposedly will capture (in a router log) ALL LAN packets, which can be downloaded. But it is not replicating a port, in which case I can not use my own software to capture packets.
Back to the drawing board.

 

[RMerlin]

The idea is to put the switch between the modem and the router, rather than on your LAN. Then using Port Mirroring, having your traffic capture set on the destination port. For instance, modem on port 1, router on port 2, and monitoring on port 3. Have port 1 mirrored (copied) to port 3.

In theory this should work, as long you have a DHCP connection. A PPPoE connection would require capturing from the router itself (or moving the PPPoE client upstream from the switch).

See the Port Mirroring section of the manual:

http://www.downloads.netgear.com/files/GS108T_GS110TP_SWA_5Nov10.pdf

 

[Klueless]

I talked to Netgear re the GS108t and the tech person said that this switch can will not replicate the router WAN port to another switch port. You can specify a LAN source and LAN destination port. She suggested their FVS318N router which supposedly will capture (in a router log) ALL LAN packets, which can be downloaded. But it is not replicating a port, in which case I can not use my own software to capture packets.
Back to the drawing board.

Must admit I got a chuckle out of this. Netgear tech support vs. RMerlin? Smart money always goes with RMerlin : -)

(While you're sorting all this out let's go back to Colin Taylor's earlier point. There is the off-chance you're having an intermittent problem with your ISP. Load up PingPlotter and let it run all day. Then, when you have an outage, take a look at its charts and see what it showed at that point in time ... vs. how it looked when all was well. You might get lucky. In fact, if you run it from the same sta you're observing the problem from, PingPlotter just might show a problem with your local network.)​

 

[dieter]

I will certainly run PingPlotter to see what shows up.
Thanks.

 

[Klueless]

Here's a PingPlot of a short outage we had with our ISP. It shows we were running good and then ... bam.

 

[dieter]

Thanks, Running the standard version of PP now...
How come yours shows 192.168.1.1? I'm testing to Google, and my router does not show.

 

[Klueless]

Thanks, Running the standard version of PP now...
How come yours shows 192.168.1.1? I'm testing to Google, and my router does not show.

Not sure. I was on wireless (through a range extender) when I ran that pplot so maybe it was like a "hop" to get there? I will try to run from a router port someday and see if that changes.

(As an aside I was noticing about 6% packet loss to my router so I put some time into cleaning up wireless. Now I run all day with no loss.)

 

[ColinTaylor]

Thanks, Running the standard version of PP now...
How come yours shows 192.168.1.1? I'm testing to Google, and my router does not show.

Can you show us a screen shot?

What is the first hop? Is it another device on your LAN?

What kind of Internet connection do you have? i.e. cable, PPPoE?

 

[dieter]

Comcast cable. No other device. Using WiFi from one computer and hardwired from another.
Hop-1 = NetName CABLE-1, Organization Comcast IP Services, L.L.C. (CISL-5)

 

[ColinTaylor]

I think I remember seeing this kind of thing occasionally in the past. It's sounds like your router isn't decrementing the TTL value. I wouldn't worry about it.

 

[Klueless]

What shows when you run a tracert and then ping your router address?

 

[dieter]

I have found major packet loss from Hop 4 (to Google) at 7:00pm to 7:40pm. But not from Hop 3 and Hop 5 (Comcast). I interpret this (from the PP documentation) to be a problem with that device. I have uploaded the PP file (file.txt has to be renamed to .PP2) , not that I expect you to diagnose this... I will run PP some more to see if it repeats.

Dieter

 

[ColinTaylor]

That's nothing to be worried about. ICMP packets are regarded as low priority, non-essential. If an intermediate router comes under heavy load it will start to drop these packets. That's normal.

You're only really concerned about the last (destination) hop. If you're dropping packets there you can then look back and see where the trouble started. In Kluless's example in post #29 you can see the problem was with hop #3 which effected everything that followed it.

 

[Klueless]

That's nothing to be worried about. ICMP packets are regarded as low priority, non-essential. If an intermediate router comes under heavy load it will start to drop these packets. That's normal.

You're only really concerned about the last (destination) hop. If you're dropping packets there you can then look back and see where the trouble started. In Kluless's example in post #29 you can see the problem was with hop #3 which effected everything that followed it.

Colin is absolutely correct!

 

[Klueless]

How come yours shows 192.168.1.1? I'm testing to Google, and my router does not show.

I think Colin's probably right (TTL), what shows when you tracert to www.google.com?

 

[dieter]

The same route that shows up in PP, no 192.168.1.1

Thanks everyone for your help.