• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 423
  • Last Modified:

monitoring network traffic without knowing the destination or source

I have a situation where there are two networks seperated by cisco routers, running IP IOS.  One at a specific time seems to send data to the other network in a one way direction.  

Im trying to figure out where the traffic is going to... and where it is coming from... This could be a security problem, it could be a networking problem, it could be user related problem, or it could even be natural and needed... unfortunately records do not indicate when exactly this started.

What are some recommendations for finding the source and destination of traffic, without actually knowing the source or destination.  While a packet sniffer would probably do the job unfortunately the network infrastructure on both sides is composed of non intelligent switches connected directly via wire to the routers which only direct traffic to its appropriate destination, it is concievable to break that connection, place a hub and sniff traffic, but that is actually hard due to circumstances beyond my control.

Thanks for any suggestions.
5 Solutions
Some manageable switches allow you to designate an "echo port" (terms used to describe it will vary) that recieves copies of all frames handled by the switch, or all frames to/from a specific other port (or group of ports).
RMON/SNMP allows packet capture on the routers without physical reconfiguration of the network

use, winarpspoof.

It will modify the arp table and let you capture all the traffic on any sniffer. e.g. ethereal.

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

If there isn't a lot of traffic between those networks, you can simply configure "ip accounting" on the router interface on the destination network, and it will list the number of bytes and packets between pairs of source and destination IP addresses. That should show you who is sending IP packets to whom. The command syntax is just that: "ip accounting" (you have to be in config mode on the specific interface).

For example, if the router interface on the destination network was FastEth0/1, you would type (in enabled mode):

conf t
int fast 0/1
ip accounting

Then you just run "show ip accounting" when ever you want, and it will show you the latest table. You can clear the stats but typing "clear ip accounting".
Instead of ip accounting, you can use netflow and export the flow stats to a collector.
NTOP is a freeware flow collector:

To enable it on the router(s)

Router(config)# ip cef
Router(config)# interface ethernet 1/0
Router(config-if)# ip flow ingress
Router(config-if)# ip route-cache flow

Router(config)# ip flow-export version 5 | 9
Router(config)# ip flow-export destination 9997

It would be really useful to tell us how you find out about this traffic. Does it bother you for some reason, are there any delays?? One really secure way to cut this traffic is to set detailed access lists .What kind of traffic do you have regularly between this two networks .Allow this kind of traffic only with an implicit deny at the end of the access list. If this unspecific traffic you describes remains means that is part of the interest traffic or from the routing protocols negotiations.
All those solutions are complex, use prashsax's suggestion and download winarpspoof.  This will trick your routers into routing the packets through the sniffing computer.  It requires no hardware changes and can be run on any computer attached to the network.

once the software is running open a network sniffer to analyze the data.

Hope that helps...

Featured Post

Get quick recovery of individual SharePoint items

Free tool – Veeam Explorer for Microsoft SharePoint, enables fast, easy restores of SharePoint sites, documents, libraries and lists — all with no agents to manage and no additional licenses to buy.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now