Packet Captures
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 |
DHCP.cap 5.8 KB
Submitted Sep 29, 2009 by pierky
R0 is the client and R1 is the DHCP server. Lease time is 1 minute.
Packets: 12 | Duration: 153s | Downloads: 11468 |
DHCP_Inter_VLAN.cap 2.0 KB
Submitted Sep 30, 2009 by pierky
R1 is a router-on-a-stick. It receives a DHCP Discover on the trunk interface, it sets the "Relay agent IP address" to the sub-interface's IP address it received the packet on and, finally, it forwards it to the DHCP server. Capture perspective is R1-DHCP server link.
Packets: 4 | Duration: n/a | Downloads: 11392 |
DHCP_MessageType 10,11,12 and 13.cap 1.9 KB
Submitted Jan 31, 2011 by Jawahar
Access Concentrator/router queries lease for particular IP addresses using message type as "DHCP LEASE QUERY" and gets response as DHCP LEASE ACTIVE,LEASE UNASSIGNED and LEASE UNKNOWN.
Access Concenttrator/Router IP=10.10.39.14
DHCP server IP=10.10.35.33
Packets: 6 | Duration: 13s | Downloads: 13490 |
DHCPv6.cap 1.6 KB
Submitted Mar 4, 2015 by fxs007
sample dhcpv6 client server transaction solicit(fresh lease)/advertise/request/reply/release/reply.
Packets: 12 | Duration: 13s | Downloads: 10008 |
DNS Question & Answer.pcapng.cap 1.6 KB
Submitted Apr 16, 2014 by manjesh23
DNS Question and Answer
Packets: 2 | Duration: n/a | Downloads: 9730 |
EoMPLS.cap 7.0 KB
Submitted Oct 12, 2009 by pierky
Routers at 1.1.2.1 and 1.1.2.2 are PEs in a MPLS cloud. LDP starts at packet 8 and they build up a pseudo-wire VC (last FEC in packets 11 and 13). At packet 15 we already have STP running between CE1 and CE2 (two routers with ESW), encapsulated in 2 MPLS headers. All the ethernet stuff follows: CDP, ARP, ICMP between two hosts on the same subnet.
Packets: 56 | Duration: 32s | Downloads: 11498 |
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 |
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 |
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_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 |
IPv6_RTSP.cap 15.5 KB
Submitted Jan 12, 2012 by Jawahar
This capture contains IPv6_RTSP packets. Accessed IPv6 enabled RTSP server using 6in4 tunnel.
Packets: 17 | Duration: 3s | Downloads: 7325 |
ISAKMP_sa_setup.cap 2.0 KB
Submitted Sep 14, 2009
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.
Packets: 9 | Duration: n/a | Downloads: 12247 |
LDP_Ethernet_FrameRelay.pcap.cap 2.1 KB
Submitted Dec 5, 2009 by pierky
LDP with pseudowire FEC elements (Ethernet and Frame-Relay DLCI-to-DLCI)
Packets: 14 | Duration: 7s | Downloads: 9652 |
LDP_adjacency.cap 5.7 KB
Submitted Sep 14, 2009
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.
Packets: 61 | Duration: 108s | Downloads: 9751 |
OCSP-Good.cap 3.5 KB
Submitted Jun 8, 2011 by kerlenpondi
OCSP_Good (CRL HTTPS CA Verisign)
Packets: 14 | Duration: 1s | Downloads: 8911 |
Open Network Connection.pcapng.cap 26.8 KB
Submitted Jul 2, 2014 by correia_ramos
Open Network Connection
ARP DNS HTTP IP MEDIA NBDGM NBNS NTP SMB TCP UDP XML
Packets: 116 | Duration: 387s | Downloads: 5016 |
PIM-DM_pruning.cap 10.2 KB
Submitted Sep 14, 2009
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.
Packets: 38 | Duration: 415s | Downloads: 7053 |
RADIUS.cap 775 bytes
Submitted Sep 14, 2009
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".
Packets: 4 | Duration: n/a | Downloads: 15696 |
RIPv1.cap 876 bytes
Submitted Sep 14, 2009
A RIPv1 router periodically flooding its database. Capture perspective from R1's 10.0.1.1 interface.
Packets: 6 | Duration: 65s | Downloads: 7673 |
RIPv1_subnet_down.cap 1.0 KB
Submitted Sep 14, 2009
RIPv1 routes are being flooded on the R1-R2 link. R2's connection to 192.168.2.0/24 goes down, and the route is advertised as unreachable (metric 16) in packet #5. Capture perspective from R1's 10.0.1.1 interface.
Packets: 8 | Duration: 58s | Downloads: 6518 |
RIPv2.cap 1.7 KB
Submitted Sep 14, 2009
A RIPv2 router periodically flooding its database. Capture perspective from R1's 10.0.0.1 interface.
Packets: 12 | Duration: 141s | Downloads: 10402 |
RIPv2_subnet_down.cap 1.3 KB
Submitted Sep 14, 2009
RIPv2 routes are being flooded on the R1-R2 link. R2's connection to 192.168.2.0/24 goes down, and the route is advertised as unreachable (metric 16) in packet #7. Capture perspective from R1's 10.0.0.1 interface.
Packets: 10 | Duration: 86s | Downloads: 8552 |
SNMPv2c_get_requests.cap 894 bytes
Submitted Sep 14, 2009
SNMPv2c get requests are issued from a manager to an SNMP agent in order to monitor the bandwidth utilization of an interface.
Packets: 8 | Duration: n/a | Downloads: 8085 |
SNMPv3.cap 1.3 KB
Submitted Oct 7, 2015 by nra
This is a SNMPv3 (IPv4) Captures.Where SNMP manager is requesting to SNMP agent using SNMPv3.
SNMP Manager: 192.168.29.58 SNMP agent: 192.168.29.160 SNMP ver: 3 Level: AuthPriv Authentication: MD5 Encryption: AES 128
Regards Suman S
Packets: 8 | Duration: 10s | Downloads: 8351 |