I'm going to take this offlist as it's really a question of Kenneth's ISP,
not ntop.
-----Burton 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Kenneth Porter
Sent: Thursday, June 09, 2005 11:25 AM
To: [email protected]
Subject: RE: [Ntop] Traffic not addressed to me

--On Tuesday, June 07, 2005 6:24 PM -0500 Burton Strauss
<[EMAIL PROTECTED]> wrote:

> if a switch is sending you bogus
> traffic, that's a problem with the switch (probably overflowed it's 
> MAC address tables - either that or it's seen the same address on 
> multiple ports - stuff like that causes a switch to operate as a hub 
> so it doesn't lose traffic - it's your problem on the device end to throw
away junk).

I got this reply from the hoster:

> Okay, now it doesn't look so strange. All the pieces are working as 
> they should.
>
> Let me try to explain what's happening. First, they are seeing ARP 
> requests and broadcasts for different networks on the same VLAN 
> because there are five different subnets sharing that VLAN (also 
> called a bridge group). That's not unusual.
>
> BVI2 is up, line protocol is up
> Internet address is 66.28.71.17/28
> Broadcast address is 255.255.255.255
> Address determined by non-volatile memory MTU is 1500 bytes Helper 
> address is not set Directed broadcast forwarding is disabled Secondary 
> address 66.28.14.49/28 Secondary address 66.28.238.1/27 Secondary 
> address 66.28.23.65/26 Secondary address 38.113.32.1/24
>
> I hope that makes sense. Now, the next one is going to be a bit more 
> difficult to explain. I need to start with a short explanation of how 
> a switch decides how to forward frames. When a switch first starts up, 
> it doesn't know anything about how to send frames to the devices 
> connected to it. It learns by watching the incoming frames and 
> building a table of MAC addresses associated with each port. If the 
> switch does not know how to get to a particular device (by its MAC 
> address), then it sends it out every port. This is called Unicast 
> Flooding. Another case where the frames are sent out every port is when
the frame is a broadcast.
>
> The table that is built has a timeout value, it is usually 300 seconds.
> So, if the switch hasn't seen any frames from that device for 5 
> minutes, it does a Unicast Flood on any frames sent to it.
>
> So, that appears to be what's happening. The switch is not seeing any 
> packets from that device for over 5 minutes, so it drops it from the 
> table and does the Unicast Flood.

_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop

_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop

Reply via email to