|
All captures
Viewing 21 - 40 of 76 captures
Auto-RP.cap (726 bytes)
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. PIM-SM_join_prune.cap (3.8 KB)
A host on R4's 172.16.20.0/24 subnet requests to join the 239.123.123.123 group. R4 sends a PIMv2 join message up to the RP (R1). Subsequent join messages are sent every 30 seconds, until R4 determines it no longer has any interested hosts and sends a prune request (packet #45). PIMv1 RP-Reachable messages for the group are also visible from R1. mtrace.cap (238 bytes)
mrinfo_query.cap (182 bytes)
PIM-DM_pruning.cap (10.2 KB)
The multicast source at 172.16.40.10 begins sending traffic to the group 239.123.123.123, and PIM-DM floods the traffic down the tree. R4 has no group members, and prunes itself from the tree. R2 and R3 then realize they have no members, and each prunes itself from the tree. The capture shows R2 receiving the multicast traffic flooded from R1 and subsequently pruning itself every three minutes. PIMv2_hellos.cap (528 bytes)
Routers 1 and 2 exchange PIMv2 hello packets. IGMPv2_query_and_report.cap (438 bytes)
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. BGP_notification.cap (764 bytes)
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_soft_reset.cap (2.0 KB)
R1 performs a soft bidirectional reset ( BGP_hard_reset.cap (3.2 KB)
A hard reset ( IBGP_adjacency.cap (2.3 KB)
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. EBGP_adjacency.cap (2.7 KB)
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 IPv6_in_IP.cap (1.5 KB)
ICMPv6 echos across an IPv6-in-IP tunnel. EIGRPv2_subnet_transition.cap (5.3 KB)
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)
Routers 1 and 2 form an EIGRPv2 adjacency and exchange IPv6 routes.
ICMPv6_echos.cap (1.3 KB)
Five ICMPv6 echo requests and their subsequent replies between routers 1 and 2. IPsec_ESP-AH_tunnel_mode.cap (2.1 KB)
Encrypted ICMP across an IPsec tunnel. AH and ESP headers are present. ISAKMP_sa_setup.cap (2.0 KB)
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)
Direct IP-in-IP tunnel encapsulation (configured in Cisco IOS with GRE.cap (1.5 KB)
ICMP is encapsulated into a Generic Routing Encapsulation (GRE) tunnel. |
Navigation
Armory
Online Toolbox
|