|
Category » Routing protocols
Viewing 1 - 20 of 39 captures
OSPF_with_MD5_auth.cap (4.6 KB)
An OSPF adjacency is formed between two routers configured to use MD5 authentication.
BGP_AS_set.cap (1.6 KB)
Packet #15 includes a BGP update containing both an AS sequence and an AS set in its AS path attribute.
OSPFv3_with_AH.cap (10.7 KB)
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_multipoint_adjacencies.cap (11.5 KB)
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_NBMA_adjacencies.cap (12.9 KB)
Router 3 forms OSPFv3 adjacencies with routers 1 and two across the non-broadcast multiaccess (NBMA) frame relay link.
OSPFv3_broadcast_adjacency.cap (5.4 KB)
Routers 1 and 2 form an OSPFv3 adjacency across their common Ethernet link (2001:db8:0:12::/64).
LDP_adjacency.cap (5.7 KB)
PE1 and P1 multicast LDP hellos to 224.0.0.2 on UDP port 646. They then establish an adjacency on TCP port 646 and exchange labels. MSDP.cap (4.1 KB)
R2 and R3 become MSDP peers and exchange keepalives. A multicast source 172.16.40.10 begins sending traffic to group 239.123.123.123, and R2 begins sending periodic source active messages to R3. Capture perspective is the R2-R3 link. PIMv2_bootstrap.cap (712 bytes)
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)
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. 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 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.
|
Navigation
Armory
Online Toolbox
|