ISAKMP_sa_setup.cap (2.0 KB)
|Packets: 9||Duration: n/a||Downloads: 4123|
An ISAKMP session is established prior to setting up an IPsec tunnel. Phase one occurs in main mode, and phase two occurs in quick mode.
IP_in_IP.cap (1.5 KB)
|Packets: 10||Duration: n/a||Downloads: 5360|
Direct IP-in-IP tunnel encapsulation (configured in Cisco IOS with
tunnel mode ipip).
ipv6_neighbor_spoofing.cap (6.2 KB)
|Packets: 49||Duration: 27s||Downloads: 3950|
IPv6 neighbor spoofing on the local link using a forged ICMPv6 neighbor advertisement.
IPv6_NDP.cap (2.1 KB)
|Packets: 20||Duration: 41s||Downloads: 6032|
Neighbor Discovery Protocol (NDP) uses ICMPv6 to perform duplicate address detection and address resolution. Also includes multicast listener reports.
IPv6_in_IP.cap (1.5 KB)
|Packets: 10||Duration: n/a||Downloads: 4794|
ICMPv6 echos across an IPv6-in-IP tunnel.
IPsec_ESP-AH_tunnel_mode.cap (2.1 KB)
|Packets: 10||Duration: n/a||Downloads: 5191|
Encrypted ICMP across an IPsec tunnel. AH and ESP headers are present.
IGMPv2_query_and_report.cap (438 bytes)
|Packets: 6||Duration: 126s||Downloads: 3778|
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 22.214.171.124.
ICMP_across_frame_relay.cap (1.2 KB)
|Packets: 10||Duration: n/a||Downloads: 3325|
A Cisco 3725 pinging its neighbor across a point-to-point frame relay connection.
ICMP_across_dot1q.cap (1.7 KB)
|Packets: 15||Duration: 35s||Downloads: 5057|
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.
ICMPv6_echos.cap (1.3 KB)
|Packets: 10||Duration: n/a||Downloads: 3207|
Five ICMPv6 echo requests and their subsequent replies between routers 1 and 2.
IBGP_adjacency.cap (2.3 KB)
|Packets: 17||Duration: 63s||Downloads: 3407|
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.
HSRP_failover.cap (3.0 KB)
|Packets: 39||Duration: 47s||Downloads: 3452|
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.
HSRP_election.cap (3.7 KB)
|Packets: 49||Duration: 57s||Downloads: 3259|
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.
HSRP_coup.cap (3.9 KB)
|Packets: 51||Duration: 49s||Downloads: 2906|
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.
HDLC.cap (3.4 KB)
|Packets: 38||Duration: 111s||Downloads: 3214|
ICMP across an HDLC serial link.
GRE.cap (1.5 KB)
|Packets: 10||Duration: n/a||Downloads: 6457|
ICMP is encapsulated into a Generic Routing Encapsulation (GRE) tunnel.
GLBP_election.cap (8.4 KB)
|Packets: 80||Duration: 68s||Downloads: 2878|
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.
Ethernet_keepalives.cap (1012 bytes)
|Packets: 13||Duration: 120s||Downloads: 2678|
Loopback keepalives transmitted by an Ethernet interface.
EIGRP_subnet_up.cap (1.3 KB)
|Packets: 15||Duration: 18s||Downloads: 3796|
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.
EIGRP_subnet_down.cap (1.8 KB)
|Packets: 21||Duration: 23s||Downloads: 2940|
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.
EIGRP_goodbye.cap (1.3 KB)
|Packets: 15||Duration: 43s||Downloads: 3381|
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.
EIGRP_adjacency.cap (5.1 KB)
|Packets: 53||Duration: 104s||Downloads: 4127|
Formation of an EIGRP adjacency between routers R1 and R2. Capture point is R1's 10.0.0.1 interface.
EIGRPv2_subnet_transition.cap (5.3 KB)
|Packets: 49||Duration: 65s||Downloads: 2993|
R4's 2001:db8:0:400::/64 subnet goes down, then comes back up roughly thirty seconds later. Capture perspective from R1's 2001:db8:0:12::1 interface.
EIGRPv2_adjacency.cap (4.1 KB)
|Packets: 31||Duration: 52s||Downloads: 3145|
Routers 1 and 2 form an EIGRPv2 adjacency and exchange IPv6 routes.
EBGP_adjacency.cap (2.7 KB)
|Packets: 24||Duration: 182s||Downloads: 3421|
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.
DTP.cap (934 bytes)
|Packets: 10||Duration: 120s||Downloads: 3819|
Dynamic Trunking Protocol (DTP) emanated from a Catalyst 3560 every 60 seconds, both with and without ISL encapsulation.
BGP_soft_reset.cap (2.0 KB)
|Packets: 17||Duration: 180s||Downloads: 3214|
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.
BGP_notification.cap (764 bytes)
|Packets: 9||Duration: n/a||Downloads: 3121|
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.
BGP_hard_reset.cap (3.2 KB)
|Packets: 32||Duration: 208s||Downloads: 3055|
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.