Unexplained packet sourcing!

Unexplained packet sourcing!

Post by H » Sun, 18 Nov 2001 08:16:23



Hi, I've a very very weird thing happen to me today and I wonder if anyone
could explain it!

A customer received a large phone bill from their Telco, because of calls to
their ISP from a Cisco 800 router.  The router interfaces and Ethernet LAN
and an ISDN line and has a very basic configuration - a single dialer.

I removed the router from the LAN and found it to still be triggering it's
own calls to the ISP.  I ran debug ip packet (Det) on it and found it to be
reacting to a request from a public IP address.  Obviously this must be
stored on the router somewhere - but I cannot explain it.

The router is NOT running any routing protocols, it has no static NAT and is
filtering NETBIOS traffic!  The inside address is 10.10.10.x and the ISP
dialer's IP address is negotiated.

I reloaded the router and hey-presto the problem went away!!  But for how
long??   Could this be a result of a hack?

THANKS

 
 
 

Unexplained packet sourcing!

Post by Vincent Jon » Sun, 18 Nov 2001 10:30:20



>Hi, I've a very very weird thing happen to me today and I wonder if anyone
>could explain it!

>A customer received a large phone bill from their Telco, because of calls to
>their ISP from a Cisco 800 router.  The router interfaces and Ethernet LAN
>and an ISDN line and has a very basic configuration - a single dialer.

>I removed the router from the LAN and found it to still be triggering it's
>own calls to the ISP.  I ran debug ip packet (Det) on it and found it to be
>reacting to a request from a public IP address.  Obviously this must be
>stored on the router somewhere - but I cannot explain it.

>The router is NOT running any routing protocols, it has no static NAT and is
>filtering NETBIOS traffic!  The inside address is 10.10.10.x and the ISP
>dialer's IP address is negotiated.

>I reloaded the router and hey-presto the problem went away!!  But for how
>long??   Could this be a result of a hack?

Until another TCP connection is left open when the ISDN line drops
due to inactivity. It appears to be part of the firewall feature set
maintaining state information on open connections and trying to close
the connection when it times it out. Of course, since the IP address is
negotiated at call placement, the close will fail and retries will be
scheduled for futile future attempts at closure.

Good luck and let us know if you can get a resolution on this.

--
Dr. Vincent C. Jones, PE              Expert advice and a helping hand
Networking Unlimited, Inc.            for those who want to manage and
Tenafly, NJ  Phone: 201 568-7810      control their networking destiny
http://www.networkingunlimited.com

 
 
 

1. Unexplained packet loss

The past few days we've been running some packet loss tests with our
SmartBits SB-200 tester (a great product!) against a Nortel Accelar
1100 and a Cisco 2924CXL switch.  One of the tests involves sending a
unidirectional stream of packets from two of the SB-200 ports into two
ingress switch ports.  All of this traffic is directed back to the SB-
200 through a third egress switch port.  We then let the SB-200 measure
the packet loss rate (in percent) for each injected stream. We've been
injecting a combined load into the ingress ports that we know will
exceed the capacity of the egress port.  We definitely expect to see
some packet loss, but the packet loss we're actually seeing is hard to
explain.  I would expect that if we inject a load of "X" percent (of
theoretical maximum) into both ingress ports, then we should see a
packet loss of X-50% for each port.  For example, if we inject a load
of 100% into both ingress ports, then we should see a packet loss of
about 50% on each port (i.e. 100%-50% = 50%).  Similarly, if we inject
a load of 50% into both ports, we should see no packet loss (i.e. 50%-
50% = 0%).  Intuitively that makes sense and in fact our testing yields
exactly those results for both the Accelar and the Cisco switches.  The
wierd thing is that for loads between 50% and 100% we see much more
packet loss than the X-50% formula and common sense would predict.  The
greatest unexplained packet loss occurs around 70%, which is more or
less centered between 50% and 100%.  Furthermore, the actual packet
loss we see from both the Nortel and the Cisco products is almost
identical.  It also doesn't seem to matter what packet size we use.
There must be something about the way these switches work internally
that is causing this.  Either that or my "common sense" assumptions are
way off base.  Can anyone out there explain this very strange switch
behavior?

Thanks,
Dave O
--
David Oltman, Systems Engineer
Triton Network Systems
http://www.triton-network.com/

Sent via Deja.com http://www.deja.com/
Before you buy.

2. Left-to-Right and Right-to-Left Paragraphs

3. Unexplained packet drops

4. PPTP on SBS

5. Tracing packet source and destination?

6. autodisconnect

7. Finding out source and destination on appletalk packets

8. Color schemes

9. packet filtering by source and type

10. Is it possible to filter incoming packets based on source UDP port #?

11. Does cisco implement source routing of IP packets ?

12. Problems with source-routed packets

13. Is it possible to send IP packets with loopback address as source addr ?