Packet Captures
IP_in_IP.cap 1.5 KB
Submitted Sep 14, 2009
Direct IP-in-IP tunnel encapsulation (configured in Cisco IOS with tunnel mode ipip).
| Packets: 10 | Duration: n/a | Downloads: 12509 |
IPv6_in_IP.cap 1.5 KB
Submitted Sep 14, 2009
ICMPv6 echos across an IPv6-in-IP tunnel.
| Packets: 10 | Duration: n/a | Downloads: 10670 |
IPsec_ESP-AH_tunnel_mode.cap 2.1 KB
Submitted Sep 14, 2009
Encrypted ICMP across an IPsec tunnel. AH and ESP headers are present.
| Packets: 10 | Duration: n/a | Downloads: 13734 |
IGMPv2_query_and_report.cap 438 bytes
Submitted Sep 14, 2009
R1 issues IGMPv2 general membership queries to the 172.16.40.0/24 segment every 60 seconds. A host replies to each query reporting it belongs to the multicast group 239.255.255.250.
| Packets: 6 | Duration: 126s | Downloads: 8804 |
ICMP_across_frame_relay.cap 1.2 KB
Submitted Sep 14, 2009
A Cisco 3725 pinging its neighbor across a point-to-point frame relay connection.
| Packets: 10 | Duration: n/a | Downloads: 6261 |
ICMP_across_dot1q.cap 1.7 KB
Submitted Sep 14, 2009
A ping issued from 192.168.123.2 to 192.168.123.1 is encapsulated with an IEEE 802.1Q header, placing it in VLAN 123.
| Packets: 15 | Duration: 35s | Downloads: 11981 |
IBGP_adjacency.cap 2.3 KB
Submitted Sep 14, 2009
Routers 3 and 4 form an internal BGP relationship. This is evidenced by the OPEN messages in packets #4 and #5, which show both routers belong to the same AS (65300). Also note that IBGP packets are not subject to a limited TTL as are EBGP packets.
| Packets: 17 | Duration: 63s | Downloads: 7940 |
HSRP_failover.cap 3.0 KB
Submitted Sep 14, 2009
R1 is the active router, R3 is the standby, and R2 is passive. R1 goes offline and R3 takes over as active after ten seconds. R2 is then promoted to the standby state.
| Packets: 39 | Duration: 47s | Downloads: 7592 |
HSRP_election.cap 3.7 KB
Submitted Sep 14, 2009
The Ethernet link shared by routers 1, 2, and 3 comes online. R1 wins the HSRP election because it has a priority of 200 (versus the default of 100 held by the other two routers). R3 becomes the standby router.
| Packets: 49 | Duration: 57s | Downloads: 7038 |
HSRP_coup.cap 3.9 KB
Submitted Sep 14, 2009
Initially only routers 3 (active) and 2 (standby) are online. R1 comes online with a priority higher than R3's. R1 takes over as the active router (the coup occurs in packet #22) almost immediately. R2 is bumped down to passive and R3 becomes the standby router.
| Packets: 51 | Duration: 49s | Downloads: 6245 |
HDLC.cap 3.4 KB
Submitted Sep 14, 2009
ICMP across an HDLC serial link.
| Packets: 38 | Duration: 111s | Downloads: 6916 |
GRE.cap 1.5 KB
Submitted Sep 14, 2009
ICMP is encapsulated into a Generic Routing Encapsulation (GRE) tunnel.
| Packets: 10 | Duration: n/a | Downloads: 18936 |
GLBP_election.cap 8.4 KB
Submitted Sep 14, 2009
Routers 1, 2, and 3 participate in a GLBP election. R1 becomes the AVG due to having the highest priority (200), and R3 becomes the standby GLBP. All three routers become AVFs.
| Packets: 80 | Duration: 68s | Downloads: 6057 |
EIGRP_subnet_up.cap 1.3 KB
Submitted Sep 14, 2009
R4's 192.168.4.0/24 subnet is brought online. R1 receives updates from both R2 and R3 (only R2's update is shown in the capture). The poison-reverse in packet #9 informs R2 not to use R1 as a path to 192.168.4.0/24. The capture perspective is from R1's 10.0.0.1 interface.
| Packets: 15 | Duration: 18s | Downloads: 8055 |
EIGRP_subnet_down.cap 1.8 KB
Submitted Sep 14, 2009
R4's interface to 192.168.4.0/24 goes down and the route is advertised as unreachable. Queries are issued by all routers to find a new path to the subnet but none exists, and the route is removed from the topology. Capture perspective is from R1's 10.0.0.1 interface.
| Packets: 21 | Duration: 23s | Downloads: 6065 |
EIGRP_goodbye.cap 1.3 KB
Submitted Sep 14, 2009
R2 designates its interface facing R1 as passive. The final hello message from R2 (packet #9) has all its K values set to 255, designating the message as a "goodbye." Capture perspective is from R1's 10.0.0.1 interface.
| Packets: 15 | Duration: 43s | Downloads: 7669 |
EIGRP_adjacency.cap 5.1 KB
Submitted Sep 14, 2009
Formation of an EIGRP adjacency between routers R1 and R2. Capture point is R1's 10.0.0.1 interface.
| Packets: 53 | Duration: 104s | Downloads: 10287 |
EBGP_adjacency.cap 2.7 KB
Submitted Sep 14, 2009
The external BGP adjacency between routers 1 and 2 is brought online and routes are exchanged. Keepalives are then exchanged every 60 seconds. Note that the IP TTL (normally 1) has been increased to 2 with ebgp-multihop to facilitate communication between the routers' loopback interfaces.
| Packets: 24 | Duration: 182s | Downloads: 8162 |
BGP_soft_reset.cap 2.0 KB
Submitted Sep 14, 2009
R1 performs a soft bidirectional reset (clear ip bgp soft) on its adjacency with R2. The ROUTE-REFRESH message is visible in packet #7. Note that the TCP connection remains uninterrupted, and neither router views the reset as disruptive.
| Packets: 17 | Duration: 180s | Downloads: 6761 |
BGP_notification.cap 764 bytes
Submitted Sep 14, 2009
R1 has been misconfigured to expect R2 to reside in AS 65100. R2 attempts to peer with R1 advertising itself correctly in AS 65200. R1 issues a NOTIFICATION in packet #5 citing a "bad peer AS" error and terminates the TCP connection.
| Packets: 9 | Duration: n/a | Downloads: 7022 |
BGP_hard_reset.cap 3.2 KB
Submitted Sep 14, 2009
A hard reset (clear ip bgp) is performed on R1 for its adjacency with R2. Packet #7 shows R1 sending a packet with the TCP FIN flag set, indicating the connection is to be torn down. The TCP connection is then reestablished and UPDATEs are retransmitted.
| Packets: 32 | Duration: 208s | Downloads: 6656 |
BGP_AS_set.cap 1.6 KB
Submitted Sep 14, 2009
Packet #15 includes a BGP update containing both an AS sequence and an AS set in its AS path attribute.
| Packets: 18 | Duration: 1s | Downloads: 7991 |
Auto-RP.cap 726 bytes
Submitted Sep 14, 2009
Routers 2 and 3 have been configured as candidate RPs, and multicast RP announcements to 239.0.1.39. Router 1 is the RP. R1 sees the candidate RP announcements from R2 and R3, and designates R3 the RP because it has a higher IP address (3.3.3.3). R1 multicasts the RP mapping to 224.0.1.40. The capture is from the R1-R2 link.
| Packets: 9 | Duration: 239s | Downloads: 6365 |