RADIUS.cap (775 bytes)
|Packets: 4||Duration: n/a||Downloads: 6071|
A RADIUS authentication request is issued from a switch at 10.0.0.1 on behalf of an EAP client. The user authenticates via MD5 challenge with the username "John.McGuirk" and the password "S0cc3r".
PPP_TCP_compression.cap (1.5 KB)
|Packets: 43||Duration: 3s||Downloads: 3151|
A telnet session is established to 220.127.116.11 across a PPP link performing TCP header compression. The user at 18.104.22.168 logs in with the password "cisco" and terminates the connection.
PPP.cap (3.6 KB)
|Packets: 50||Duration: 83s||Downloads: 3675|
ICMP across a PPP serial link.
PIMv2_hellos.cap (528 bytes)
|Packets: 6||Duration: 63s||Downloads: 3887|
Routers 1 and 2 exchange PIMv2 hello packets.
PIMv2_bootstrap.cap (712 bytes)
|Packets: 8||Duration: 184s||Downloads: 3315|
Router 1 is the BSR and routers 2 and 3 are candidate RPs with the default priority of 0. R1 collects the RP advertisement unicasts from R2 and R3 and combines them in a bootstrap multicast to all PIM routers. Capture perspective is the R1-R3 link.
PIM-SM_join_prune.cap (3.8 KB)
|Packets: 47||Duration: 473s||Downloads: 4523|
A host on R4's 172.16.20.0/24 subnet requests to join the 22.214.171.124 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.
PIM-DM_pruning.cap (10.2 KB)
|Packets: 38||Duration: 415s||Downloads: 3115|
The multicast source at 172.16.40.10 begins sending traffic to the group 126.96.36.199, 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.
path_MTU_discovery.cap (6.2 KB)
|Packets: 8||Duration: n/a||Downloads: 4610|
Tracepath is used to determine the MTU of the path between hosts 192.168.0.2 and .1.2. Packet #6 contains an ICMP "fragmentation needed" message, indicating the MTU for that hop is 1400 bytes.
OSPF_with_MD5_auth.cap (4.6 KB)
|Packets: 34||Duration: 63s||Downloads: 3676|
An OSPF adjacency is formed between two routers configured to use MD5 authentication.
OSPF_type7_LSA.cap (3.6 KB)
|Packets: 25||Duration: 32s||Downloads: 3900|
Area 10 is configured as a not-so-stubby area (NSSA). The capture records the adjacency formed between routers 2 and 3. The link state update in packet #11 includes several type 7 LSAs from R2. Capture perspective from R3's 10.0.10.1 interface.
OSPF_point-to-point_adjacencies.cap (9.9 KB)
|Packets: 93||Duration: 35s||Downloads: 4487|
The frame relay network between four routers is configured with point-to-point subinterfaces. No DR/BDR is required as all adjacencies are point-to-point. Capture perspective from R1.
OSPF_NBMA_adjacencies.cap (11.7 KB)
|Packets: 99||Duration: 66s||Downloads: 3373|
Formation of OSPF adjacencies across a Non-broadcast Multiaccess (NBMA) frame relay topology. Neighbors have been manually specified on all routers, with R1 configured to become the DR. No BDR is present. Capture perspective from R1.
OSPF_multipoint_adjacencies.cap (16.3 KB)
|Packets: 196||Duration: 277s||Downloads: 4096|
Routers 1 through 4 are configured to view the non-broadcast frame relay network as a point-to-multipoint topology. Adjacencies are formed without the need of a DR or BDR. Note that inverse ARP was used to dynamically learn the addresses of neighbors.
OSPF_LSA_types.cap (4.0 KB)
|Packets: 30||Duration: 63s||Downloads: 4665|
Capture of adjacency formation between OSPF routers 4 and 5 in area 20. Packet #12 contains LSAs of types 1, 2, 3, 4, and 5.
OSPF_broadcast_adjacencies.cap (8.4 KB)
|Packets: 74||Duration: 95s||Downloads: 4114|
Three routers form OSPF adjacencies across a broadcast segment. All interface priorities are left default, so R3 (with the highest router ID) becomes the DR, and R2 (with the next-highest router ID) becomes the BDR. Capture perspective from R1.
OSPFv3_with_AH.cap (10.7 KB)
|Packets: 61||Duration: 170s||Downloads: 3834|
The adjacency between R1 and R2 in the 2001:db8:0:12::/64 subnet is configured with IPsec AH authentication. Note the inclusion of an IPsec AH header immediately following the IPv6 header of each OSPF packet.
OSPFv3_NBMA_adjacencies.cap (12.9 KB)
|Packets: 86||Duration: 90s||Downloads: 2888|
Router 3 forms OSPFv3 adjacencies with routers 1 and two across the non-broadcast multi-access (NBMA) frame relay link.
OSPFv3_multipoint_adjacencies.cap (11.5 KB)
|Packets: 73||Duration: 35s||Downloads: 2941|
The frame relay link connecting routers 1, 2, and 3 has been configured as a point-to-multipoint network with broadcast capability. Router 3 forms OSPFv3 adjacencies with routers 1 and 2, but no DR or BDR is elected.
OSPFv3_broadcast_adjacency.cap (5.4 KB)
|Packets: 38||Duration: 70s||Downloads: 3285|
Routers 1 and 2 form an OSPFv3 adjacency across their common Ethernet link (2001:db8:0:12::/64).
NHRP_registration.cap (648 bytes)
|Packets: 4||Duration: n/a||Downloads: 3271|
R2 registers a multipoint GRE tunnel with R1. Capture perspective from the R1-R5 link.
mtrace.cap (238 bytes)
|Packets: 2||Duration: n/a||Downloads: 2849|
mtrace 172.16.40.1 172.16.20.1 is issued on R1 to trace the RPF path from R4's 172.16.20.0/24 subnet to R1's 172.16.40.0/24 subnet. The capture is taken on the R1-R3 link.
MSDP.cap (4.1 KB)
|Packets: 35||Duration: 391s||Downloads: 2957|
R2 and R3 become MSDP peers and exchange keepalives. A multicast source 172.16.40.10 begins sending traffic to group 188.8.131.52, and R2 begins sending periodic source active messages to R3. Capture perspective is the R2-R3 link.
mrinfo_query.cap (182 bytes)
|Packets: 2||Duration: n/a||Downloads: 2649|
mrinfo 184.108.40.206 is issued on R1. DVMRPv3 is used to query R2 for its multicast interfaces.
MPLS_encapsulation.cap (1.3 KB)
|Packets: 10||Duration: n/a||Downloads: 4804|
Capture taken from the PE1-P1 link. ICMP traffic between CE1 and CE2 is encapsulated outbound with MPLS label 18. Note that returning traffic is not labeled, due to penultimate hop popping (PHP).
mGRE_ICMP.cap (3.7 KB)
|Packets: 24||Duration: 10s||Downloads: 4266|
R2 begins sending ICMP traffic to R4, but it currently only has a GRE tunnel open to R1. The first two ICMP requests (packets #1 and #4) are routed through R1 while R2 sends an NHRP request to R1 for R4's spoke address. Once a GRE tunnel is dynamically built between spoke routers R2 and R4, R2 begins routing the ICMP traffic directly to R4. Capture perspective from the R2-R5 link.
LDP_adjacency.cap (5.7 KB)
|Packets: 61||Duration: 108s||Downloads: 4090|
PE1 and P1 multicast LDP hellos to 220.127.116.11 on UDP port 646. They then establish an adjacency on TCP port 646 and exchange labels.
ISIS_p2p_adjacency.cap (21.7 KB)
|Packets: 26||Duration: 113s||Downloads: 3766|
Routers 1 and 2 form a L1/L2 adjacency over a point-to-point serial link. Note that both levels of adjacency are managed with a point-to-point (P2P) hello.
ISIS_level2_adjacency.cap (51.8 KB)
|Packets: 43||Duration: 85s||Downloads: 3575|
Routers 3 and 4 form an IS-IS level 2 adjacency.
ISIS_level1_adjacency.cap (27.4 KB)
|Packets: 22||Duration: 58s||Downloads: 3312|
Routers 2 and 3 form an IS-IS level 2 adjacency.
ISIS_external_lsp.cap (17.0 KB)
|Packets: 15||Duration: 23s||Downloads: 2972|
R2 floods the external routes redistributed from RIP into area 10. Packet #9 includes the IP external reachability TLV. Capture perspective from R3's 10.0.10.1 interface.