[afnog] QoS setting verification

[Antonio Godinho]

Unfortunately this network is at a remote location. The switch is not 
manageable, so no option of port mirroring. What usually happens is that one 
or other PC from time to time gets some malware or virus which generates 
this type of traffic for which I have put ACL's on the router but it seems 
that when this happens, the router somehow starts having problems with the 
voice traffic when it has to reject all these packets on the ethernet 
interface. If someone unplugs the ethernet cable then everything goes back 
to normal but the serial link is never affected. I thought at first that the 
voice traffic would never be affected by ethernet traffic since it "should" 
go from the voice interface through the router directly onto the serial 
interface but it seems that I was wrong. Somehow, the act of discarding 
unwanted packets at the ethernet interface affects the operation of VoIP.

Unfortunately at this point I can not measure the traffic before it hits the 
router since I am not on location (1.5 hour flight). There is also no one 
there who is knowledgable enough to do anything of the sort. Also they have 
no idea which PC is generating traffic. 

I was just wondering if there was any way I could minimise the effect of the 
ethernet problem on the router in order to have an acceptable VoIP 
connection. 

Cheers,

AG

On Fri, 21 Jul 2006 12:54:31 +0100, Brian Candler wrote
> On Fri, Jul 21, 2006 at 10:10:39AM +0200, Antonio Godinho wrote:
> > Actually the internal  network where PC1 and PC2 and PC3 are there is a 
> > switch. The router has an access list on the ethernet that will only 
allow 
> > certain type of traffic thus cutting off any other disallowed traffic. 
So 
> > you may find that PC1 is bombarding the router with traffic since the 
router 
> > is the default gateway and the router is trashing all this traffic 
because 
> > it is illegal traffic
> 
> That explanation doesn't make sense. If the router has an access 
> list which blocks a certain packet, then either:
> 
> (1) it will drop the packet on the floor, or
> (2) it will send back an ICMP "Admin Prohibited" message
> 
> But neither of these actions should cause the client to "bombard" 
> the router with additional traffic.
> 
> For example, If the client is trying to open a TCP session, then TCP 
> will retry at intervals - typically once after 3 seconds, again 
> after 6 seconds, again after 12 seconds etc. That's a tiny amount of 
> traffic.
> 
> If it's UDP (say a DNS request) then the client will retry a few 
> times, again at intervals of a few seconds.
> 
> If the client is running a ping, then it's unlikely to send more 
> than one ping every second. This is regardless of whether a response 
> is received or not.
> 
> None of these will generate a full ethernet's worth of traffic from 
> a single client.
> 
> So, I think you need to capture an example of this "bombardment" to 
> find out what's actually going on. If you know which client it's 
> coming from, then run ethereal/tcpdump on the client. If you don't,
>  then use port mirroring on the switch and capture everything to a 
> Unix box running tcpdump.
> 
> Maybe you have a broken piece of client software which floods the 
> link with traffic.
> 
> Regards,
> 
> Brian.


--
Antonio Godinho
B.Sc., MCP+I, MCSE, CCNA, CCNP
CIUEM
Maputo
Mozambique