Archive
Poor mans packet filter
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.
Using routed VPLS for aggregation and troubleshooting
Everyone surely knows about SVIs, they’re great. They allow you to groom many physical links in to a subnet. If I want to do this on a Cisco that’s all very straightforward, it’s probably one of the first things you learn. Not so easy on a 7750.
Because the 7750 is a service router it isn’t designed to operate as a closet switch. It’s a mean, lean provider router and has a specific purpose. One recent-ish development I came across was the routed VPLS solution. It’s a simple concept, it’s easy to implement but it’s hardware specific. You need to use IOM3 or IMMs to do it which can be sucky, especially if you need its functionality on something like an SR1. This post will look at two scenarios: aggregation and troubleshooting
Aggregation:
OK, I get a request in that a HA pair of voice devices need to be connected in. They must be in the same subnet but they don’t support many features such as VRRP, LACP and I don’t want to do any pre aggregation because that adds extra points of failure, latency which we don’t want for the traffic type. We can’t run any FHRP on the PE so we need to take everything in at layer 2 and have a logical binding to layer 3 in there somehow. My immediate thoughts would be to use an SVI, it’s simple and well understood across operational teams. Unfortunately as we now know this isn’t supported on my 7750. What about using group interfaces? This is where you can aggregate broadband subscribers to a single subnet from multiple MSANs, sounds positive. Unfortunately all testing indicates it’s not going to work, confirmed by the vendor TAC. What can we do then? Didn’t I read something about binding a layer 2 service to a layer 3 interface? Why yes I did. Enter rVPLS.
I need to take 4 connections from a centralized server HA pair and terminate them on a single IP address on the PE. rVPLS allows me to do this by binding a VPLS service to a VPRN. It will look something like this physically.
The first thing you need to do is create the services. If we look at the VPLS first there are only a couple of commands needed outside of a standard configuration, we will put in some make believe SAPs too:
config service vpls 1234
allow-ip-int-binding
service-name "routed vpls"
sap 1/1/1:100
sap 1/1/2:100
sap 2/1/2:100
That’s pretty much it for the VPLS. We need to bind it to our layer 3 interface and we’re done:
config service vprn 4321
interface "gateway" create
address 10.10.10.10/24
vpls "routed vpls"
By specifying vpls "routed vpls" under the interface instead of a SAP or SDP allows hosts on the VPLS to use 10.10.10.10 as their gateway. It’s certainly elaborate compared to an SVI but I do like the concept, giving us more service flexibility.
Troubleshooting:
Here we have a layer 2 broadband aggregation service, the MSAN (CO/FTTx) terminates on an IMM48 and for many reasons we may not have a layer 3 interface to ping from. This is the perfect time to use a routed VPLS if we need to test reachability.
This is a scenario I have used in lab work but never in production. The reason I have not used it in a live environment is you have OAM commands available to carry out diagnostics (cpe ping etc) and therefore probably don’t need it. Of course if you accidentally use an already allocated address it can be impacting to a customer. Use this at your own peril.
So what is the setup? We have a single physical interface to the MSAN from the PE carrying multiple services. Each tagged service comes in to a distinct VPLS on the PE. As this is the last point from the MPLS network to the end user it’s a good place to prove a problem off the core network and in to the access layer.
Our goal here is to configure an ‘interception point’ in to the layer 2 network so we may pin point the fault location further.
If we reuse the configuration from the aggregation example we would simply need to apply the allow-ip-int-binding/service-name commands to the VPLS, create the random VPRN 4321 and set the service name under the VPRN interface, exactly as we did above. Basically this is allowing us to put an intermediate layer 3 pointer in to a layer 2 only service. Once we have completed the configuration steps we can ping the home user. Of course this could be filtered by the end user, the MSAN may have security measures but you get the point, the same logic applies to all media.
A:PE# ping router 4321 10.10.10.143
PING 10.10.10.143 56 data bytes
64 bytes from 10.10.10.143: icmp_seq=1 ttl=64 time=0.150ms.
64 bytes from 10.10.10.143: icmp_seq=2 ttl=64 time=0.125ms.
^C
ping aborted by user
---- 10.10.10.143 PING Statistics ----
2 packets transmitted, 2 packets received, 0.00% packet loss
round-trip min = 0.125ms, avg = 0.137ms, max = 0.150ms, stddev = 0.015ms
So you see we can use this to jump in the middle of PPP sessions to test the connection to the customer or upstream if the BRAS is off the MPLS network domain. Added to that if we have a native ethernet network of 7750s, with no MPLS, then we can use this technique to pin point the problem area in the switched network. I have no idea why you wouldn’t have MPLS if you splashed out on IMMs for your 7750s though! 😀
As a final example before I have some ice cream what if we sell a managed CE service but the core network is using a VPLS. We could use CFM, Y.1731 to measure connectivity. Maybe our end point CE doesn’t support these protocols but it does support IP SLA. We could set an rVPLS interface on each PE and run a local IP SLA echo to measure connectivity in the event of an attachment circuit failure.
I have not tried it before but I think I might. Maybe you know or want to try it for the craic yourself, race ye!
iamjeffvader's studymotron and rantatorium 