How to check source IP in Lan

Unanswered Question
Aug 12th, 2007

Dear Experts ,

We have 6500 switch in our Lan and so many users are terninated on this switch.we have two uplinks to outside world i.e internet from this switch.One of the user is accessing site which he is not suppose to access.

If i enable ip accouting output packets on the interfaces connecting to internet, i think i can be able to see the source & destination Ip's.I know the destination IP .

Is there any other command or procedure to check which source is accessing that particular destination Ip.

Thanks :)


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
guruprasadr Sun, 08/12/2007 - 22:33

HI Satish,

"Netflow" Tool can able to provide the statistics based on your requirement.

Pls refer "Netflow" implementation Manuals in cisco web.

Hope i am Informative ! !

Best Regards,

Guru Prasad R

smothuku Mon, 08/13/2007 - 00:47

Hi Guru ,

Thanks for u r reply...I've gone through Netflow on 6500 switch ..I would like to know if we go for netflow implementation on 6500 which is core switch what could be the cpu utilisation of 6500 ? does it effect 6500 performance ?



smothuku Mon, 08/13/2007 - 00:44

Hi ,

Thanks for u r reply.If we apply an access-list we can see only the no.of matches, not the source ip which is accessing that destination ..Am i correct ?

But we need to know the source ip asap and 6500 is the core is very urgent..



Jon Marshall Mon, 08/13/2007 - 00:49


If you add the keyword "log" to the end of the line ie.

access-list 101 permit ip any host "destination IP" log

access-list 101 permit ip any any

then you should get the source IP logged. Only log the first line otherwise you'll get flooded.



royalblues Mon, 08/13/2007 - 00:59

Use the log-input keyword at the end of the access-list

The log-input in the access list will create records in syslog and these records will show the individual destination addresses.

But using netflow would be a better option as this would have less overhead on the router



guruprasadr Mon, 08/13/2007 - 01:06

HI Satish, [RATE All Helpful Posts]

Adding a key-word "log" will not help.

Whereas "NETFLOW" Tool on Core 6500 Device will have a considerable CPU Overhead only neverthless consider the current CPU Load of the Device before the Implementation.

You can actually capture the "Statistics" with the help of "Netflow" tool based on Port-basis where you really require (ie., on Specific Ports where you want to Track / Monitor) rather than running the "Netflow" capture for Entire Switch itself. This is one way of keeping the CPU Overhead in Control while using the "Netflow" Tool.

INFO: Netflow has an feature of scanning the Interfaces for Attacks. By disabling such feature (if not required in your environment means) will help to keep the CPU Overhead of Switch under Control.

Hope i am Informative ! !


Best Regards,

Guru Prasad R

Since you already know the destination IP you can give the ACL similar to that given below

access-list 111 permit ip any host destination_ip log

access-list 111 permit ip any any

This should show the source ip in the log.

You mentioned that you can use ip accounting but is there any alternative ip accounting not working? Or you want to be doubly sure?


*(Hope This Doesn't Hurt :-)

Richard Burts Mon, 08/13/2007 - 02:52

I agree that NetFlow would seem to be the optimum choice. It is my understanding that in using NetFlow the aspect that impacts CPU utilization is exporting the flow information. The generation of the flow statistics is mostly a byproduct of the routing process and the CPU required to generate the statistics is pretty low. Since I do not believe that this discussion is suggesting that the flow statistics be exported I believe that the CPU impact is fairly low.

In terms of impact on CPU I would be careful about using the log option on the access list. Depending on the amount of traffic that matches and that would be logged there could be considerable CPU load required for the logging activity. In a previous post Jon suggested logging only the first packet of a session but did not provide details or an example. The logging of the first packet works particularly well for TCP traffic. I would suggest that this version of the access list would give the necessary identification of the source address and minimize the CPU impact:

access-list 101 permit tcp any host established

access-list 101 permit tcp any host log

access-list 101 permit ip any any




This Discussion