Showing posts with label wireshark. Show all posts
Showing posts with label wireshark. Show all posts
Friday, June 3, 2011
Debugging IPv6 MTU issues in Windows
A common problem you might face soon (World IPv6 Day is 5 days away) is reachability to IPv6 sites due to MTU issues. ICMPv6 has a nice internal mechanism which is supposed to help the application overcome these issues, but like in the IPv4 world, not everything is perfect.
Let's suppose that an IPv6 subscriber is using a DSL router and is connected through PPPoE to a BRAS.
TARGET <=> BRAS <=> DSL-ROUTER <=> HOST
The usual MTU for PPPoE connections is 1492 bytes, as shown below.
1500 bytes = Ethernet Payload
- 6 bytes = PPPoE header
- 2 bytes = PPP ID
---------------------------------
1492 bytes = IPv6 Packet that can be carried over a PPPoE connection
If your host is configured with 1492 (or something lower) as MTU on its LAN interface, then the OS running on it will automatically take care of "fragmentation", so you don't need to worry for anything. Unfortunately this isn't a common scenario by default. You either have to configure it manually on the host or if you are lucky enough and the DSL modem supports advertisement of MTU to its LAN interface through RA messages (and your host accepts them), it will happen automatically.
If your host is configured with anything larger than 1492 on its LAN interface (in most cases it's the default of 1500), problems might arise.
Users with hosts running Windows can try to ping an IPv6 address (i.e. the next hop after the DSL router) in order to find possible issues with the MTU. The closer the target is, the easier it will be to troubleshoot the problem. Then you start moving towards the target until you meet the issue.
First, some numbers you will need regarding the various headers
1492 bytes = IPv6 Packet
- 40 bytes = IPv6 Header
- 8 bytes = ICMPv6 Header
-------------------------------
1444 bytes = ICMPv6 payload data
Since Windows ping uses the actual payload as a size, if you want to send a total of 1492 bytes, you have to send 1492-40-8=1444 bytes of ICMPv6 payload data. Anything larger will lead to either a problem or to fragmentation.
Windows>ping -l 1444 x:x::x Pinging target [x:x:xx] with 1444 bytes of data: Reply from x:x:xx: time=53ms Reply from x:x:xx: time=51ms Reply from x:x:xx: time=54ms Reply from x:x:xx: time=53ms Ping statistics for x:x:xx: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 51ms, Maximum = 54ms, Average = 52ms
These are the relevant Wireshark captures.
The ICMP conversation between all involved devices
1444 bytes ICMP request from HOST to TARGET
If you increase the above number, you'd better start looking for "Too big" ICMPv6 received messages from any hop towards the target, otherwise you are in trouble.
i.e. if you ping with 1446 bytes of data, you get the following:
Windows>ping -l 1446 x:x:xx Pinging target [x:x:xx] with 1446 bytes of data: Packet needs to be fragmented but DF set. Reply from x:x:xx: time=53ms Reply from x:x:xx: time=55ms Reply from x:x:xx: time=57ms Ping statistics for x:x:xx: Packets: Sent = 4, Received = 3, Lost = 1 (25% loss), Approximate round trip times in milli-seconds: Minimum = 53ms, Maximum = 57ms, Average = 55ms
These are the relevant Wireshark captures.
The ICMP conversation between all involved devices (fragmentation included))
1446 bytes ICMP request from HOST to TARGET
ICMP reply ("Too big") from DSL-ROUTER to HOST (original truncated message included)
As you can see, device DSL-ROUTER is replying with "Too Big" message in the first packet to the HOST and informs it about the MTU (1492) supported in the next-hop link (see RFC 4443 for ICMPv6 info); that's the WAN link towards the BRAS, where PPPoE is running on.
If you are in the unfortunate position to not get any incoming packets, you can safely assume (if everything else is fine) that someone in the path is blocking ICMPv6 messages.
The reply message is exactly 1280 bytes, which is the minimum packet size IPv6 supports. This leads to the original message being truncated in the reply message to 1280-40=1240 bytes for the ICMPv6 packet or 1240-8-40-8=1184 bytes for the actual payload data. So you loose 1446-1184=262 bytes of payload data in the reply message.
Next packets get a successful answer from the target, because they are sent as fragmented (1432+14 bytes).
1432 bytes ICMP request from HOST to TARGET
14 bytes ICMP request from HOST to TARGET
Windows is "smart" enough to keep track of this status for some minutes (in the so called destination or route cache), so next time you send large packets, the first packet is not lost, because fragmentation happens right away.
Windows>ping -l 1446 x:x:xx Pinging target [x:x:xx] with 1446 bytes of data: Reply from x:x:xx: time=54ms Reply from x:x:xx: time=53ms Reply from x:x:xx: time=55ms Reply from x:x:xx: time=52ms Ping statistics for x:x:xx: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 52ms, Maximum = 55ms, Average = 53ms
Imho, it's better to make your host use the appropriate MTU from the beginning (i.e. hardcode 1492 or use RA's value) and not depend on ICMPv6 messages to do fragmentation. Some people have proposed to always use the minimum of 1280 (Geoff Huston, Tore Anderson), in order to be safe on every possible case (tunnels involved). I generally prefer to use the maximum possible, hoping that someone in the middle won't mess with ICMPv6 messages. I know that currently this is not the case (so stick with something lower, like 1280, for now), but this will probably change as native IPv6 gets deployed. Unless we start filtering ICMPv6 messages uncontrollably...like many do on IPv4. Does "Internet Control Message Protocol" say anything to you?
Notes
1) RFC 1982 describes Path MTU Discovery (PMTUD) for IPv6.
2) RFC 4821 will help a lot in PMTUD, when and if all vendors start implementing it.
3) In order to see clearly the fragmented IPv6 packets in Wireshark, you have to disable reassembly in preferences.
4) You can use the commands "ipv6 rc" and "ipv6 rcf" in order to view and clear the destination/route cache in WindowsXP
Saturday, August 28, 2010
Decoding the RIPE BGP experiment
A lot of you probably saw your BGP routers go crazy on Friday 27th of August in the morning, especially if you happened to have a CRS (or another router running IOS-XR, like a C12k or ASR9k) in your (or a near) network.
RIPE and Duke University decided to experiment with Quagga's BGP and the result was to make some routers reset their BGP sessions, because they were receiving malformed BGP update packets. Malformed packets were generated by other routers in the middle, not by the Quagga BGP daemon where the experiment started.
Error messages generated on BGP routers that had peerings with affected (i.e. IOS-XR) routers, were like the following:
%BGP-3-NOTIFICATION: sent to neighbor x.x.x.x 3/1 (update malformed) 188 bytes F0630BB8 00000000 00000000 00000000 00
BGP: x.x.x.x Bad attributes FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0118
0200 0000 FD40 0101 0040 0206 0202 0D1C 316E 4003 04C3 10A1 6180 0404 0000 0000 4005 0400 0000 3CC0 081C 0D1C 0002 0D1C 0016 0D1C 0056 0D1C
01F7 0D1C 029A 0D1C 0813 FDE8 FDDE F063 0BB8 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 185D AF90
According to BGP's RFC, the "3/1" in the error message translates to Code "UPDATE Message Error" and Subcode "Malformed Attribute List".
Wireshark offers an "easy" way to decode packets in ASCII format, as long as you feed them in the right way. The following perl script (which is based on my previous ciscodump2text) will convert the BGP packet included in the above Cisco error messages into a format that can be understood by Wireshark's text2pcap.
#!/opt/perl/bin/perl
#
# bgpdump2text v0.1
#
# Convert BGP packets included in Cisco BGP notification error messages
# to a special text format that can then be fed into text2pcap
# so a pcap file for Wireshark can be created at the end.
# You have to remove any extra characters included in the error messages.
#
# Copyright (C) 2010 Tassos (http://ccie-in-3-months.blogspot.com)
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see http://www.gnu.org/licenses/.
@packets = ();
$first_line = 0;
while () {
$line = $_;
if ( ( $line =~ /^FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF/ ) || ( $first_line == 1 ) ) {
$first_line = 1;
$line =~ s/\s//g;
$packets[1] .= $line;
}
}
for ($i = 1; $i <= @packets; $i++) {
if ( exists $packets[$i] ) {
for ( $j = 0; $j < length($packets[$i]); $j += 2 ) {
if ( $j == 0 ) {
printf "# BGP Packet $i\n%08X", $j/2;
} elsif ( $j % 32 == 0 ) {
printf " #\n%08X", $j/2;
}
print " ".substr($packets[$i], $j, 2);
}
print " #\n";
}
}
print "\n";
By using as input a text file with the BGP packet as shown in the original error message, you'll get an output text file ready to be processed by text2pcap.
The format the source text file (test-bgp.text) should have is the following.
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0118 0200 0000 FD40 0101 0040 0206 0202 0D1C
316E 4003 04C3 10A1 6180 0404 0000 0000 4005 0400 0000 3CC0 081C 0D1C 0002 0D1C 001
6 0D1C 0056 0D1C 01F7 0D1C 029A 0D1C 0813 FDE8 FDDE F063 0BB8 0000 0000 0000 0000 00
00 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0
000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 000
0 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 185D AF90
You just need to erase all extra characters from the original error message and it's ready. The actual data starts after the "Bad attributes" string. Keep in mind that the packet might have been spitted in more than one messages, like in the above case. Just remove the initial characters from every line and it'll be ok.
Script is executed like below:
tassos$ bgpdump2text test-bgp.text> test-bgp.txt
The generated text file (test-bgp.txt) will have the following contents:
# BGP Packet 1
00000000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF #
00000010 01 18 02 00 00 00 FD 40 01 01 00 40 02 06 02 02 #
00000020 0D 1C 31 6E 40 03 04 C3 10 A1 61 80 04 04 00 00 #
00000030 00 00 40 05 04 00 00 00 3C C0 08 1C 0D 1C 00 02 #
00000040 0D 1C 00 16 0D 1C 00 56 0D 1C 01 F7 0D 1C 02 9A #
00000050 0D 1C 08 13 FD E8 FD DE F0 63 0B B8 00 00 00 00 #
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
000000A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
000000C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
000000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
00000110 00 00 00 00 18 5D AF 90 #
Note : right now, only one packet can be processed.
In our case (BGP data only) we need to add a L2 header, an IP header and a TCP header with values that resemble BGP, so we add the required parameters in the text2pcap program:
C:\Program Files\Wireshark>text2pcap.exe -T 179,1025 -d test-bgp.txt test-bgp.pcap
Input from: test-bgp.txt
Output to: test-bgp.pcap
Generate dummy Ethernet header: Protocol: 0x800
Generate dummy IP header: Protocol: 6
Generate dummy TCP header: Source port: 179. Dest port: 1025
Start new packet
Wrote packet of 280 bytes at 0
-------------------------
Read 1 potential packet, wrote 1 packet
Now, if you load this pcap file into Wireshark, you'll get the following output:
As you can clearly see, there was an unknown attribute (with Type Code 99) inserted into the UPDATE message with the following characteristics:
Flags: Optional, Transitive, Partial, Extended Length
Type code : 99
Length : 3000 bytes
The length of the BGP UPDATE message has been defined as 280 in the BGP header, having 253 as total path attribute length, so something went clearly wrong.
This unknown attribute should have a length of 3000 bytes as defined in its length attribute, but it was only 184 bytes if you count the octets from where zeros start (after 0x0BB8) till the end. From this number comes 188 (184 + 4 for Flags/TypeCode/Length), the number that's included in the initial error message.
So, the length of the unknown attribute has been defined as 3000 into the packet, which is 0x0BB8 in hex. If you somehow remove the first octet, then it becomes 0xB8, which is 184 in decimal. If you add the 4 extra bytes (Flags, Type code, Length), then it becomes 188 and the sum of all attributes becomes 253, which is the one shown in the packet too.
In reverse order, if you calculate the supposed total path attribute length in case all attributes were correct, then it should be 3069, which is 0x0BFD in hex. If again you somehow remove the first octet, it becomes 0xFD (253).
I guess, in general anything larger than 0xFF (255) would have caused the same issue too.
Cisco issued an advisory after some hours, providing fixes for its IOS-XR software.
Regarding the behavior of BGP, the relevant RFC (4271) says the following, so everything was expected:
NOTIFICATION messages are sent in response to errors or special conditions. If a connection encounters an error condition, a NOTIFICATION message is sent and the connection is closed.
...
A NOTIFICATION message is sent when an error condition is detected. The BGP connection is closed immediately after it is sent.
...
Error checking of an UPDATE message begins by examining the path attributes. If the Withdrawn Routes Length or Total Attribute Length is too large (i.e., if Withdrawn Routes Length + Total Attribute Length + 23 exceeds the message Length), then the Error Subcode MUST be set to Malformed Attribute List.
There is also a lot of discussion happening regarding the notification and reset thing after this event and draft-ietf-idr-optional-transitive seems quite interesting.
Links
http://mailman.nanog.org/pipermail/nanog/2010-August/024837.html
http://www.networkworld.com/news/2010/082710-research-experiment-disrupts-internet-for.html
http://www.renesys.com/blog/2010/08/house-of-cards.shtml
https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment/
Question
Is there a chance by creating "dummy" and large attributes to cause memory issues on BGP routers?
Sunday, April 19, 2009
Convert Cisco dumps into Wireshark's pcap format
Lately i've been experimenting a lot with the hidden "dump" option of "debug ip packet", trying to decode various protocols. Yesterday i wrote a post about decoding the tacacs communication, something that required a little bit of awkward text editing.
Tonight i created the following perl program in order to make the whole process easier.
#!/opt/perl/bin/perl
# ciscodump2text v0.1
#
# Convert Cisco hex dump format (captured through the "debug ip packet dump" command)
# to a special text format that can then be fed into text2pcap
# so a pcap file for Wireshark can be created at the end
#
# Copyright (C) 2009 Tassos (http://ccie-in-3-months.blogspot.com)
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
@packets = ();
$junk_line = 1;
$i = 0;
while () {
$line = $_;
if ( $line =~ /^[0-9A-F]{8}: / ) {
$hex_part = substr($line, 10, 36);
$hex_part =~ s/\s//g;
if ( $junk_line ) {
$i++;
$packets[$i] = "";
$junk_line = 0;
};
$packets[$i] .= $hex_part;
} else {
$junk_line = 1;
}
}
for ($i = 1; $i <= @packets; $i++) {
if ( exists $packets[$i] ) {
for ( $j = 0; $j < length($packets[$i]); $j += 2 ) {
if ( $j == 0 ) {
printf "# Packet $i\n%08X", $j/2;
} elsif ( $j % 32 == 0 ) {
printf " #\n%08X", $j/2;
}
print " ".substr($packets[$i], $j, 2);
}
print " #\n";
}
}
print "\n";
You just give it the cisco dump as input (only lines starting with an 8-char hex number are processed, so you don't have to worry about other lines) and it produces a text file that can be fed into text2pcap. Then you give text2pcap the new text file as input and it produces a pcap file as output, which can be opened with Wireshark.
i.e. we want to convert the following log produced by "debug ip packet dump" to a text file compatible with the "text2pcap" program.
*Apr 18 18:19:51.887: FIBipv4-packet-proc: route packet from (local) src 10.10.10.9 dst 10.10.10.10
*Apr 18 18:19:51.887: FIBipv4-packet-proc: packet routing succeeded
*Apr 18 18:19:51.887: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 80, sending
*Apr 18 18:19:51.887: TCP src=20596, dst=49, seq=1187787226, ack=3815757335, win=4128 ACK
082D17D0: 45000050 678B0000 E..Pg...
082D17E0: FF062BF6 0A0A0A09 0A0A0A0A 50740031 ..+v........Pt.1
082D17F0: 46CC31DA E36FD617 50101020 9F960000 FL1ZcoV.P.. ....
082D1800: C0010100 99648E6A 0000001C B8145EC8 @....d.j....8.^H
082D1810: A8B3C2B9 3EC12A1F AA40DE66 D7429C89 (3B9>A*.*@^fWB..
082D1820: 0BF911F3 C7249F5F .y.sG$._
*Apr 18 18:19:51.887: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 80, sending full packet
*Apr 18 18:19:51.887: TCP src=20596, dst=49, seq=1187787226, ack=3815757335, win=4128 ACK
082D17C0: 0200 4C4F4F50 ..LOOP
082D17D0: CA000CB8 00060800 45000050 678B0000 J..8....E..Pg...
082D17E0: FF062BF6 0A0A0A09 0A0A0A0A 50740031 ..+v........Pt.1
082D17F0: 46CC31DA E36FD617 50101020 9F960000 FL1ZcoV.P.. ....
082D1800: C0010100 99648E6A 0000001C B8145EC8 @....d.j....8.^H
082D1810: A8B3C2B9 3EC12A1F AA40DE66 D7429C89 (3B9>A*.*@^fWB..
082D1820: 0BF911F3 C7249F5F .y.sG$._
*Apr 18 18:19:52.103: FIBipv4-packet-proc: route packet from (local) src 10.10.10.9 dst 10.10.10.10
*Apr 18 18:19:52.107: FIBipv4-packet-proc: packet routing succeeded
*Apr 18 18:19:52.107: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 40, sending
*Apr 18 18:19:52.111: TCP src=20596, dst=49, seq=1187787266, ack=3815757363, win=4100 ACK
080014D0: 45000028 678C0000 E..(g...
080014E0: FF062C1D 0A0A0A09 0A0A0A0A 50740031 ..,.........Pt.1
080014F0: 46CC3202 E36FD633 50101004 F4920000 FL2.coV3P...t...
08001500:
*Apr 18 18:19:52.127: IP: s=10.10.10.9 (local), d=10.10.10.10 (FastEthernet0/1), len 40, sending full packet
*Apr 18 18:19:52.131: TCP src=20596, dst=49, seq=1187787266, ack=3815757363, win=4100 ACK
080014C0: 0200 4C4F4F50 ..LOOP
080014D0: CA000CB8 00060800 45000028 678C0000 J..8....E..(g...
080014E0: FF062C1D 0A0A0A09 0A0A0A0A 50740031 ..,.........Pt.1
080014F0: 46CC3202 E36FD633 50101004 F4920000 FL2.coV3P...t...
08001500:
First we save it in a ascii/text file (i.e. "test.dump") and we give it as input to the "ciscodump2text" program.
tassos$ ciscodump2text test.dump> test.text
The created "test.text" file contains the following :
# Packet 1
00000000 45 00 00 50 67 8B 00 00 FF 06 2B F6 0A 0A 0A 09 #
00000010 0A 0A 0A 0A 50 74 00 31 46 CC 31 DA E3 6F D6 17 #
00000020 50 10 10 20 9F 96 00 00 C0 01 01 00 99 64 8E 6A #
00000030 00 00 00 1C B8 14 5E C8 A8 B3 C2 B9 3E C1 2A 1F #
00000040 AA 40 DE 66 D7 42 9C 89 0B F9 11 F3 C7 24 9F 5F #
# Packet 2
00000000 02 00 4C 4F 4F 50 CA 00 0C B8 00 06 08 00 45 00 #
00000010 00 50 67 8B 00 00 FF 06 2B F6 0A 0A 0A 09 0A 0A #
00000020 0A 0A 50 74 00 31 46 CC 31 DA E3 6F D6 17 50 10 #
00000030 10 20 9F 96 00 00 C0 01 01 00 99 64 8E 6A 00 00 #
00000040 00 1C B8 14 5E C8 A8 B3 C2 B9 3E C1 2A 1F AA 40 #
00000050 DE 66 D7 42 9C 89 0B F9 11 F3 C7 24 9F 5F #
# Packet 3
00000000 45 00 00 28 67 8C 00 00 FF 06 2C 1D 0A 0A 0A 09 #
00000010 0A 0A 0A 0A 50 74 00 31 46 CC 32 02 E3 6F D6 33 #
00000020 50 10 10 04 F4 92 00 00 #
# Packet 4
00000000 02 00 4C 4F 4F 50 CA 00 0C B8 00 06 08 00 45 00 #
00000010 00 28 67 8C 00 00 FF 06 2C 1D 0A 0A 0A 09 0A 0A #
00000020 0A 0A 50 74 00 31 46 CC 32 02 E3 6F D6 33 50 10 #
00000030 10 04 F4 92 00 00 #
Then, we convert this new text file into a pcap file by using the "text2pcap" program, which is included with Wireshark.
tassos$ text2pcap.exe" -d test.text test.pcap
Input from: test.text
Output to: test.pcap
Start new packet
Start new packet
Wrote packet of 80 bytes at 0
Start new packet
Wrote packet of 94 bytes at 80
Start new packet
Wrote packet of 40 bytes at 174
Wrote packet of 54 bytes at 214
-------------------------
Read 4 potential packets, wrote 4 packets
The resulting pcap file "test.pcap" can be opened for further processing with Wireshark.
That way you can very easily create pcap files of almost everything happening on your router.
Notes : The "dump" option is supported since 12.0 IOS. Latest IOS includes EPC, which makes the whole capture & convert-to-pcap process much easier.
PS : I'm not a very good perl programmer (although i have written a lot of custom perl scripts for my job), so someone playing with perl for years will probably produce a more compact "perlish" code. I just tried to interpret my logic into perl code.
Posted by Tassos at 04:27 8 comments
Subscribe to:
Comments (Atom)