Cisco Tips & Tricks

May 7, 2006

Turning the router in to Packet sniffer

Filed under: Access-lists — ciscotips @ 5:43 am

I see lot of posts on the net on troubleshooting of different applications being used on the network. People try to rely on third party sniffers to see what is happening. But do you know we can create a small sniffer script and add to make things lot more easier in troubleshooting. Moreover, Many applications need access through an access control list (ACL) on a router, but you might not know what ports or protocols to allow in the ACL rules. Simply use an access list and the router’s logging function to “sniff” and report what it sees.Take a transparent approach to locking the ACL down to only what is needed. The process takes some time, but is effective and can be used on virtually any interface ACL.

Follow these steps:

1. Discover: Use the router’s ability to log ACL matches in its own buffer in order to catalog the traffic that crosses it. The configuration is the following:

Router (config)# logging buffered 15000 (this creates a large enough buffer to look at locally on the router,or you can configure the router to log the ACL matches to a Syslog server).

Router (config)# access-list 101 permit tcp any gt 0 any gt 0 log

Router (config)# access-list 101 permit udp any gt 0 any gt 0 log

Router (config)# access-list 101 permit icmp any any

Router (config)# access-list 101 permit ip any any log (this entry is a “catch-all”)

Router (config)# interface interfaceRouter (config-if)# ip access-group 101 in

Look at the log by using the show log command from the exec prompt. You should see IP addresses (source and destination), along with the used TCP or UDP ports (in parentheses):

Mar 18 20:05:10.628: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 192.168.19.137(50051) -> 10.2.9.30(15648), 1 packet

Mar 18 20:05:20.697: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 192.168.19.137(50054) ->10.2.9.30(15648), 1 packet

Mar 18 20:05:30.757: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 192.168.19.137(50057) ->10.2.9.30(15648), 1 packet

Mar 18 20:05:40.854: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 192.168.19.137(50060) ->10.2.9.30(15648), 1 packet

Mar 18 20:05:51.006: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 192.168.19.137(50063) ->10.2.9.30(15648), 1 packet

Mar 18 20:06:01.115: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 192.168.19.137(50115) ->10.2.9.30(15648), 1 packet

Mar 18 20:06:10.354: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 192.168.19.137(50118) ->10.2.9.30(15648), 1 packet

Mar 18 20:06:20.423: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 192.168.19.137(50121) ->10.2.9.30(15648), 1 packet

When using earlier IOS versions you can specify permit ip any any log or permit tcp any any log. This showsyou the port numbers in the show log command. However, with later IOS versions, using these permit statements produces a port zero (0) in the show log command, which is why I use statements such as permit TCP any gto any gto log. This produces the TCP port numbers. The same goes for UDP.

In this example, two IP addresses need to communicate, and the destination TCP port is 15648. The source port changes, so I cannot create a static ACL for that port. I can create a TCP ACL that states:

access-list 101 permit tcp host 192.168.19.137 host 10.2.9.30 eq 15648

This should be sufficient for a tight access list. Using this information, I can create a new access list.

2. Notify: Even though we do not expect any connectivity issues, notify those who could be affected by an error or an unexpected condition during this process.

3. Implement: We do not want to interrupt a production environment to make changes. I used this method:

Router (config)# interface interface

Router (config-if)# no ip access-group 101 in(Removes the ACL from active service)

Router (config-if)# exit (I could use Crtl+Z here as well)

Router (config)# exitRouter# ena

Router (config)# no access-list 101 (Now go and delete the ACL.)

If you use “named” access lists, you can edit out individual access-list entries. I use Microsoft Notepad to edit the access list from the configuration by pasting it into the Telnet/SSH session. Next, Iadd the new access list:

Router (config)# access-list 101 permit tcp host192.168.19.137 host 10.2.9.30 eq 15648

Router (config)# access-list 101 permit tcp any gt 0any gt 0 log

Router (config)# access-list 101 permit udp any gt 0any gt 0 log

Router (config)# access-list 101 permit icmp any any

Router (config)# access-list 101 permit ip any any log

Router (config)# interface interface

Router (config-if)# ip access-group 101 in

4. Verify: Use the show access-list command and the show log command to verify that the access list is working.As the more specific access-list entries are added, the more general ones are pushed to the bottom of the list, and eventually the hit counters on the general ACL entries will be zero. Then you can delete those general ACL entries, leaving only the specific rules. The sequence of commands I used is important in retaining a transparent change to a production environment.

Using Cisco BERT to Monitor Link Quality

Filed under: Router — ciscotips @ 5:21 am

Cisco bit-error-rate testing (BERT) is a very helpful utility for monitoring link quality; just loop the suspected media at the far end, configure a BERT profile, and run a test for the needed duration. The user profiles are stored as part of the configuration in the NVRAM. We can define a maximum of 15 profiles on the system. This provides the results in terms of pass or fail. You can use the tool can to remotely verify your media from the command-line interface (CLI) and quickly isolate media problems.

!

<Define BERT Profile>

bert profile 1 pattern 211-O.152 threshold 10^-2

error-injection none duration 60

!

<Run The Test>

Router#bert controller e1 0 profile 1

<Output>

Router#show controllers e1 bert

Controller E1 0 Profile default : Test Never Ran

Controller E1 0 Profile 1 : Test passed with BER of 10^(-2) —-> [wow Media is OK till the looped end]

Controller E1 1 Profile default : Test Never Ran

Controller E1 1 Profile 1 : Test Never Ran

Controller E1 2 Profile default : Test Never Ran

Controller E1 2 Profile 1 : Test Never Ran

Controller E1 3 Profile default : Test Never Ran

Controller E1 3 Profile 1 : Test Never Ran

Controller E1 4 Profile default : Test Never Ran

Controller E1 4 Profile 1 : Test Never Ran

Controller E1 5 Profile default : Test Never Ran

Controller E1 5 Profile 1 : Test Never Ran

Controller E1 6 Profile default : Test Never Ran

Controller E1 6 Profile 1 : Test Never Ran

Controller E1 7 Profile default : Test Never Ran

Controller E1 7 Profile 1 : Test Never Ran

sh controller utilization

Filed under: Router, Technology and Software — ciscotips @ 5:16 am

Normally when we require to see the over all utilization, we bank on MRTG or other health utilization tools but for a quick referrence, one can always use following command.

The show controllers utilization command on the Cisco Catalyst 2950 (other IOS switches probably support this) running Cisco IOS Software Release 12.1.22+ shows a summary of port utilization on all ports,including percentage and backplane/fabric utilization:

2950#show controllers utilization

Port Receive Utilization Transmit Utilization

Fa0/1 0 0

Fa0/2 0 0

Fa0/3 0 0

Fa0/4 0 0

< —- truncated —- >

Total Ports : 50

Switch Receive Bandwidth Percentage Utilization : 0

Switch Transmit Bandwidth Percentage Utilization : 0

Switch Fabric Percentage Utilization : 0

This can also be done on a per-port basis using sh

controllers FastEthernet 0/1 utilization.

Theme: Silver is the New Black. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.