iamjeffvader's studymotron and rantatorium

Here is a quick post on how to capture at least some packet header information on a 7750 if you don’t have the luxury of Wireshark to hand. The 7750 allows the creation of mac and IP filters to control traffic in the same way an ACL does on an IOS device. The bonus you have with the Alcatel is that it can also log the header output to a file for review.

Creating a filter is straightforward but care must be taken to ensure you do not disrupt traffic flow when applying it.

First we will configure an IP filter using the default filter log, 101.

*A:r1# configure filter
- filter
[no] ip-filter + Configure an IP-filter
[no] mac-filter + Configure a mac-filter

As you can see we have the option to configure an IP or mac based filter. I have removed other options for now. Creating the filter itself is the first part of the process. Once done the next step is to specify the default action, in our case we want to forward all traffic. This step can be service impacting if not done correctly.

configure filter
ip-filter 99 create
default-action forward

Once that part is done we configure entries for variables we want to match against. To see all traffic we simply set the action to forward here as well. Why do we do this when we have already set the default action? There is no logging option outside of specific entries unfortunately. For the first filter we won’t bother matching anything, we want to capture all traffic.

entry 10 create
action forward
log 101

So that’s the filter done, we just need to apply it to the interface, or SAP, we want to monitor. Here I will apply it to interface tor4 and look at network traffic:

config router inter tor4 ingress filter ip 99

Now we should not have to wait long, as this interface is running OSPF we should see OSPF at least:

show filter log 101
[snip]
2013/11/20 22:19:38 Ip Filter: 99:10 Desc:
Interface: tor4 Direction: Ingress Action: Forward
Src MAC: 14-cf-a4-c0-40-5d Dst MAC: 01-00-5e-00-00-05 EtherType: 0800
Src IP: 41.41.41.4 Dst IP: 224.0.0.5 Flags: 0 TOS: c0 TTL: 1
Protocol: 89
[snip]
2013/11/20 22:19:42 Ip Filter: 99:10 Desc:
Interface: tor4 Direction: Ingress Action: Forward
Src MAC: 14-cf-a4-c0-40-5d Dst MAC: 01-00-5e-00-00-02 EtherType: 0800
Src IP: 41.41.41.4:646 Dst IP: 224.0.0.2:646 Flags: 0 TOS: c0 TTL: 1
Protocol: UDP

So what are we looking at here?

$timestamp Ip Filter: $filternumber:$entry Desc:
Interface:$interfaceID Direction: Ingress Action: Forward
Src MAC: 14-cf-a4-c0-40-5d Dst MAC: 01-00-5e-00-00-05 EtherType: 0800
Src IP: 41.41.41.4 Dst IP: 224.0.0.5 Flags: 0 TOS: c0 TTL: 1
Protocol: 89

Some of this is obvious, some not:
$timestamp: The time at which the packet was logged
$filternumber: the filter ID we configured, in this case 99
$entry: the entry we configured, i.e. 10
$interfaceID: the interface we configured the filter under

Some of the more obvious ones are we set the direction to ingress by putting the filter under ingress at the interface level. Our action on entry 10 was to forward. We are also presented with the source mac/IP which is our neighbour router (remember ingress). The destination is to all OSPF routers so this is a multicast packet. The EtherType indicates the upper layer protocol is IPv4 and the protocol number confirms this is OSPF. While it is useful to see OSPF packets it’s something that is easily seen in a debug.

The second packet in the capture is an LDP packet, an LDP hello in fact as it is UDP directed the all routers multicast address, the port number being used is 646. Maybe LDP isn’t as intuitive to debug, now you can see the traffic live. If we take a look at a mac filter the principle is the same. In this case we will place the filter on a SAP and see customer frames however first we will create a new log file, 102, to show how this is done.

config filter log 102 create
description "SAP_SNIFFER"
destination memory 100
wrap-around
no shutdown

We can send the traps to local memory or we can send them to syslog. With syslog there is more involved and people might not like you trap storming them
Now if we create and apply our mac filter:

mac-filter 99 create
default-action forward
entry 10 create
log 102
action forward
/configure service vpls 1234 sap 1/2/1:1234.0 ingress filter mac 99
show filter log 102
[snip]
2013/11/20 22:52:00 Mac Filter: 99:10 Desc:
SAP: 1/2/1:1234.0 Direction: Ingress Action: Forward
Src MAC: 00-a1-29-5d-b5-75 Dst MAC: 01-b1-c0-40-63 EtherType: 0800
Src IP: 10.9.8.1:1557 Dst IP: 10.9.10.15:162 Flags: 0 TOS: 00 TTL: 255
Protocol: UDP

This message is an SNMP trap being send from a device back to a server as it is using port 162. If we are monitoring SNMP we can leave this filter running for a while and ensure bidirectional communication is happening.
So why would you use a mac filter over an IP filter and vice versa? You can’t apply both to every interface type. In our IP filter example we applied it to a network interface, mac filters are not supported here. You need to choose the right filter for the right occasion.

If you want to look for a specific protocol it’s pretty straightforward.  Below we will edit ip filter 99 to match protocol 89.  This will then log against OSPF messages:

A:r1>config>filter>ip-filter# entry 10
A:r1>config>filter>ip-filter>entry# match protocol 89
*A:r1>config>filter>ip-filter>entry>match# back
*A:r1>config>filter>ip-filter>entry# info
----------------------------------------------
match protocol ospf-igp
exit
log 101
action forward
----------------------------------------------
*A:r1>config>filter>ip-filter>entry# /clear filter log 101
*A:r1>config>filter>ip-filter>entry# show filter log 101
[snip]
Maximum entries configured : 1000
Number of entries logged   : 1
2013/11/29 09:05:18  Ip Filter: 99:10  Desc:
Interface: tor4  Direction: Ingress  Action: Forward
Src MAC: 14-cf-a4-c0-40-5d  Dst MAC: 01-00-5e-00-00-05  EtherType: 0800
Src IP: 41.41.41.4  Dst IP: 224.0.0.5  Flags: 0  TOS: c0  TTL: 1
Protocol: 89

You can use various different protocol filters, ICMP, TCP or UDP port numbers. Filters can be a useful operational tool for troubleshooting but they can also be dangerous if used incorrectly. Practice using them in a controlled environment and add them to your troubleshooting arsenal.