Packet captures

313 packet captures

Disclaimer: You download and use files from networkstudysite.com at your own risk.

• acl-denies-traffic.pcap
• arp-frame-qinq.pcap
• arp-frame-vxlan-with-qinq.pcap
• arp-request-and-reply.pcap
• arp-request-reply-over-eompls-pseudowire.pcap * You may need to decode the capture by right-clicking on a packet, choosing "Decode As..." and selecting "Ethernet PW (with CW)" from the dropdown list, it stands for "Ethernet Pseudowire with Control Word".
• bfd-multihop-session.pcap
• bgp-add-path-send-and-receive-open-msg.pcap * Under "Optional Parameters" there is "Capability: Support for Additional Paths".
• bgp-color-extended-community-mpls-vpnv4-route.pcap * The BGP color community can be used with Segment Routing Traffic Engineering Automated Steering to identify MPLS VPNv4 destination prefixes where a specifically configured path should be used, the color community can be found under the "Path attributes" section "EXTENDED_COMMUNITIES".
• bgp-community.pcap
• bgp-authentication.pcap
• bgp-default-routes-with-different-local-preference.pcap * Four BGP default route Update messages and each has a different local preference value attached, advertised over GRE tunnel in a DMVPN redundant Hub router design.
• bgp-internet-community.pcap
• bgp-labeled-unicast-update.pcap * An IPv4 BGP Update message (not VPNv4) that carries a prefix with an MPLS label, there is no Route Distinguisher and no Route Target value attached, details can be viewed under "Path Attribute - MP_REACH_NLRI" section "Network Layer Reachability Information (NLRI)".
• bgp-large-community.pcap
• bgp-local-as-community.pcap
• bgp-multihop-ttl-value.pcap
• bgp-multiprotocol-extension-capability.pcap
• bgp-neighborship-over-l2tpv3-over-mpls.pcap * A BGP neighborship is established over an L2TPv3 tunnel which is transported over MPLS label switching.
• bgp-no-export-community.pcap
• bgp-notification-error-max-prefix.pcap
• bgp-open-and-update-ipv4-multicast-address-family.pcap
• bgp-open-as-trans-4-byte-asn.pcap * The "My AS" field contains the AS TRANS value 23456.
• bgp-open-l2vpn-vpls-address-family.pcap * Under the first "Optional Parameter: Capability" there is the "AFI: Layer-2 VPN (25)" with "SAFI: VPLS (65)".
• bgp-remotely-triggered-black-hole-subnet-discard-route.pcap * This capture shows a BGP Update message advertising the destination prefix 192.168.1.0/24 to Provider Edge (PE) routers, however the next-hop address is modified to 192.0.2.1 which is a discard route, so in essence if a PE router installs this route, then all traffic destined to 192.168.1.0/24 will be sent to the discard route and dropped, this is how BGP RTBH can protect a network by dropping malicious traffic at the network edge.
• bgp-route-distinguisher.pcap * This capture contains two different and unique BGP Update messages that lead to the same IPv4 prefix 192.168.2.0/24. Since these are actually BGP VPNv4 Updates, one route has 192.168.2.0/24 with Route Distinguisher 65100:2, while the other route has 192.168.2.0/24 with RD 65100:3 assigned. They also have different next-hop addresses. Details can be viewed under "Path Attribute - MP_REACH_NLRI" and "Network Layer Reachability Information (NLRI)" sections.
• bgp-route-reflector-cluster-list.pcap
• bgp-route-summarization.pcap
• bgp-update-4-byte-asn.pcap * In "Border Gateway Protocol - UPDATE Message" under "Path attributes" the "AS_PATH" contains 4-byte private ASNs displayed in asplain notation.
• bgp-update-as-prepend.pcap
• bgp-update-confederation-as-confed-sequence.pcap * BGP Update sent within a Confederation includes AS_CONFED_SEQUENCE in AS Path to indicate a neighboring Sub-AS.
• bgp-update-evpn-irb-ipv6-ip-prefix-route.pcap * This BGP Update advertises an EVPN IP prefix route, specifically an IPv6 destination prefix together with an MPLS VPN label, details can be verified under one of the "Border Gateway Protocol - UPDATE Message" by looking under the "Path Attribute - MP_REACH_NLRI" section and searching in the "Network Layer Reachability Information (NLRI)" for "EVPN NLRI: IP Prefix route".
• bgp-update-ipv6.pcap
• bgp-update-ipv6-over-ipv4.pcap
• bgp-vpnv4-default-route-mpls-l3vpn.pcap * BGP VPNv4 Update advertises default route in MPLS L3VPN network, this Update message also contains a BGP standard and an extended community value which are visible under the "Path Attributes".
• bgp-vpnv4-update-two-route-target-values.pcap * Under each "Border Gateway Protocol - UPDATE Message" within the "Path Attribute - EXTENDED_COMMUNITIES" the Route Target extended community can be verified.
• bgp-vpnv4-with-ospf-extended-community-mpls-l3vpn.pcap * BGP VPNv4 capture with three Update messages each carries Extended Communities that are specific to OSPF, because in this MPLS L3VPN network OSPF was used as the PE - CE routing protocol, and OSPF prefixes were redistributed on the PE router and advertised as BGP VPNv4 prefixes.
• cdp-in-native-vlan.pcap
• cdp-in-not-native-vlan.pcap * Native VLAN can be verified under "Cisco Discovery Protocol" and "Native VLAN" section.
• dhcp-discover-with-information-option-82.pcap
• dhcp-discover-broadcast-in-local-vlan.pcap * The DHCP Discover message is sent in the local subnetwork (local VLAN), and in this capture a DHCP Relay Agent answers the query, this can be verified by viewing the "DHCP Offer" message "Relay agent IP address".
• dhcp-lease-expire-without-renew.pcap
• dhcp-offer-1-minute-lease.pcap * Under "Dynamic Host Configuration Protocol" the section in "Option: (51)" specifies the Lease Time, underneath that section there are two sections which define the rules of address renewal, Option 58 "Renewal Time Value", and Option 59 "Rebind Time Value".
• dhcp-release-ipv4.pcap
• dhcpv6-information-request-and-reply.pcap
• dhcpv6-message-exchange-solicit-advertise-request-reply.pcap
• dhcpv6-rapid-commit-solicit-and-reply.pcap
• dhcpv6-relay-forward-and-reply.pcap
• dhcpv6-renew-and-reply.pcap
• dmvpn-ipv6-over-ipv4.pcap
• dmvpn-ipv6-over-ipv6.pcap
• dmvpn-nhrp-and-bgp-dynamic-neighbor.pcap
• dmvpn-phase-3-nhrp-sequence.pcap * The sequence of NHRP packets that are exchanged during DMVPN Phase 3 direct spoke-to-spoke traffic initiation, 172.16.1.2 is the hub router, 172.16.2.2 and 172.16.2.3 are the spoke routers.
• dmvpn-with-ospf-broadcast-network-type.pcap * When configuring DMVPN with OSPF broadcast network type the Hub device needs to be the OSPF Designated Router (DR), this is visible in the packet capture, the DR listens to OSPF control plane messages destined to the 224.0.0.6 multicast address, which are sent to the 172.16.1.1 NBMA (physical underlay) address, because of DMVPN the OSPF communication is encapsulated in GRE.
• dns-query-and-response.pcap
• dns-query-response-ipv6-aaaa-record.pcap
• dtp-dynamic-trunking-protocol.pcap
• eigrp-external-routes-update-redistribution.pcap * Within the "External Routes" the "External Data" section contains information about the originating routing protocol.
• eigrp-ipv4-authentication-update-md5.pcap
• eigrp-ipv6-authentication-hello.pcap
• eigrp-ipv6-hello.pcap
• eigrp-ipv6-over-ipv4-gre.pcap
• eigrp-ipv6-query-and-reply.pcap
• eigrp-ipv6-update.pcap
• eigrp-otp-lisp-encapsulation.pcap * When viewed in Wireshark, it may be necessary to manually set packet decoding. Right click on packet, then select "Decode As...", and choose "LISP Data" from the "Current" column dropdown menu in the row called "UDP port".
• eigrp-query-and-reply.pcap
• eigrp-route-tag-value.pcap * Within the "Internal Route" the "Attributes" section contains the Route Tag value, it is called "Admin Tag".
• eigrp-sha-authentication-no-keychain.pcap
• eigrp-stub-router-hello.pcap
• eigrp-summary-leak-map.pcap * EIGRP Update message contains a /16 summary prefix and a more specific /24 leaked prefix.
• eigrp-update.pcap
• eigrp-update-with-summary-and-restart-flag.pcap
• eompls-l2vpn-encapsulation-label-stack.pcap * You may need to decode the captures by right-clicking on each packet, choosing "Decode As..." and selecting "Ethernet PW (with CW)" from the dropdown list, it stands for "Ethernet Pseudowire with Control Word".
• erspan-port-mirroring-transports-telnet-for-ipsec-tunnel.pcap * This is an ERSPAN mirrored packet destined to a monitoring server, the original packet was destined to an IPSec tunnel interface (before it was mirrored by ERSPAN). The original packet has already received a GRE header which will be encrypted by IPSec/ESP, but due to ERSPAN remote tunneling this mirrored packet receives an additional GRE header (for ERSPAN transport.)
• esp-ipsec-encrypted-packet.pcap
• etherchannel-lacp-slow-protocols.pcap
• etherchannel-pagp-pdu.pcap
• evpn-mpls-frame-encapsulation.pcap * Both packets may need to be manually decoded in Wireshark, by right clicking on packet, selecting "Decode As..." and to using "Ethernet PW (no CW)", which stands for Ethernet Pseudowire no Control Word.
• evpn-mpls-route-type-5-ip-prefix.pcap * EVPN Route Type 5 carries IP prefix information, this can be verified in both BGP Update packets within "Path attributes" then "MP_REACH_NLRI" section under "Network Layer Reachability Information (NLRI)" an IP prefix is visible with an attached MPLS VPN service label.
• evpn-route-type-1-per-esi-ethernet-autodiscovery.pcap * Per-ESI Route Type 1 is used with EVPN multihoming, under "Path Attribute - MP_REACH_NLRI" "Network Layer Reachability Information (NLRI)" the "ESI:" value is not zero, and the "MPLS Label 1:" is set to zero.
• evpn-route-type-1-per-evi-ethernet-autodiscovery.pcap
• evpn-route-type-2-mac-advertisement.pcap
• evpn-route-type-2-and-route-type-3-bgp-update.pcap * This capture shows two BGP Update messages, one advertises an EVPN MAC advertisement route, and the other advertises an EVPN IMET route for multicast traffic.
• evpn-route-type-3-imet-pmsi-multicast.pcap * EVPN Route Type 3 also called Inclusive Multicast Route under "Path attributes" there is "PMSI_TUNNEL_ATTRIBUTE" which contains information about broadcast, unknown-unicast and multicast (BUM) traffic destination address within EVPN network.
• evpn-route-type-4-ethernet-segment-route.pcap * More information is available in the "evpn-multihoming-configuration-l2vpn-mpls.html" blog post
• evpn-vxlan-bgp-open-capability.pcap * Under the "Capability: Multiprotocol extensions capability" the "AFI: Layer-2 VPN (25)" and "SAFI: EVPN (70)" are visible, this address family is used by the VXLAN control plane BGP.
• evpn-vxlan-bgp-update-route-type-3-imet-pmsi-tunnel.pcap
• evpn-vxlan-data-plane-encapsulation-mac-in-udp.pcap
• evpn-vxlan-l3vni-ip-prefix-route.pcap
• evpn-vxlan-route-type-2-mac-advertisement.pcap
• flexvpn-ipsec-ikev2-exchange-spoke-to-spoke.pcap * First IKEv2 Security Association (SA) with Hub router (IP address 172.16.1.2), then dynamic IKEv2 SA with remote Spoke (IP address 172.16.3.2) using encrypted NHRP message exchange.
• ftp-file-transfer-protocol.pcap
• getvpn-gdoi-mpls-l3vpn-registering-with-key-server.pcap * GETVPN uses source and destination UDP port 848 between the Group Members (MPLS L3VPN CE routers) and the Key Server for registration and rekeying, in this capture the CE IP address is 10.0.2.2 and the Key Server's IP address is 172.16.0.1, you may need to manually decode the capture by right clicking on one of the packets, selecting "Decode As..." and choosing "ISAKMP" from the list of available protocols, further details available in the "getvpn-gdoi-mpls-l3vpn-encryption.html" blog post.
• glbp-arp-virtual-mac.pcap
• glbp-ipv4-avf-failover-hello.pcap * Router 10.0.0.2 is no longer active forwarder (AVF) for this GLBP Group, therefore in the GLBP Hello sent from 10.0.0.3 there are two "Request/Response" sections which show that 10.0.0.3 is the active forwarder for both GLBP virtual MAC addresses. Meanwhile, the router 10.0.0.2 remains the AVG for this GLBP Group, this means it replies to ARP requests from the hosts. Notice also, the Hello sent from the standby AVF 10.0.0.2 contains a "Request/Response" section with the "Priority" set to the value 39, and "VF state: Listen".
• glbp-ipv4-hello-with-authentication.pcap
• glbp-ipv6-hello-with-authentication.pcap
• glbp-ipv6-ndp-neighbor-advertisement.pcap * Host receives the GLBP vMAC address through a Neighbor Advertisement message.
• glbp-ipv6-ndp-router-advertisement.pcap * The source link-local IPv6 address is actually the virtual IPv6 address for GLBP Group 10.
• gratuitous-arp.pcap
• gratuitous-arp-hsrp.pcap
• gre-encapsulated-bgp-peering.pcap
• gre-encapsulated-ipv4-ping.pcap
• gre-encapsulated-ipv6-ping.pcap
• hsrp-ipv4-coup-state-change.pcap
• hsrp-ipv4-hello-active-standby.pcap
• hsrp-ipv6-router-advertisement-ndp.pcap * In this NDP RA message the source link-local IPv6 address is actually an HSRPv2 virtual IP which includes the HSRP Group number (decimal 10) in hexadecimal.
• hsrpv2-ipv4-hello-active-standby.pcap
• hsrpv2-ipv6-hello-message.pcap
• http-forbidden-403-error.pcap
• http-get-200-ok-html.pcap
• http-get-download.pcap
• http-put-upload.pcap * Contains HTTP PUT message and 32 TCP segments that transfer a file.
• http-scep-crypto-pki-unauthorized-client-request.pcap * When the CA-Server has an HTTP IP access-list configured to allow only authorized PKI-Clients to request certificates, the CA-Server will reset any TCP Syn request that has a source IP denied in the ACL.
• http-scep-pki-certiticate-authentication-and-enrollment.pcap * Process of certificate authentication and certificate enrollment, during authentication the PKI-Client requests the Root Certificate using the "GetCACert" message, during enrollment the PKI-Client requests an Identity Certificate using the "GetCACaps" and "PKIOperation" messages.
• http-scep-pki-certificate-based-authentication.pcap * Certificate based (PKI) authentication uses the Simple Certificate Enrollment Protocol (SCEP) which relies on HTTP to transport data, for example requesting the Root Certificate from a Certificate Authority (CA) server which is shown in this capture.
• hvpls-l2vpn-mpls-and-qinq-edge-domain.pcap * To view the details in Wireshark you need to right-click on a single packet, then select "Decode As..." and decode the "MPLS protocol" field with the "Ethernet PW (with CW)" (Ethernet Pseudowire with Control Word) option, and finally click "OK", you find details in the "hierarchical-vpls-configuration-hvpls.html" blog post.
• hvpls-l2vpn-mpls-encapsulation.pcap * To view the details in Wireshark you need to right-click on the single packet, then select "Decode As..." and decode the "MPLS protocol" field with the "Ethernet PW (with CW)" (Ethernet Pseudowire with Control Word) option, and finally click "OK", you find details in the "hierarchical-vpls-configuration-hvpls.html" blog post.
• icmp-multicast.pcap
• icmp-redirect.pcap
• icmp-qos-voice-dscp-expedited-forwarding.pcap * Within the "Internet Protocol Version 4" section under "Differentiated Services Field" the DSCP value is set to "Expedited Forwarding" which is generally used for voice traffic.
• icmpv6-over-mpls-l3vpn-segment-routing-label-stack.pcap
• igmp-v2-general-membership-query.pcap
• igmp-v2-group-specific-membership-query-multicast.pcap
• igmp-v2-leave-group-multicast.pcap
• igmp-v2-membership-report-multicast.pcap
• igmp-v3-block-old-sources-membership-report-multicast.pcap
• igmp-v3-source-specific-membership-report-multicast.pcap
• ipsec-authentication-header-gre-tunnel.pcap
• ipsec-isakmp-main-mode-quick-mode-ikev1.pcap * IPSec packet exchange used during negotiation of an IKEv1 Security Association (SA), in other words when an IPSec secure tunnel is created, these packets are exchanged, ESP is data traffic that is already encrypted after successful SA negotiation.
• ipsec-tunnel-mode-authentication-header-without-gre.pcap * A Virtual Tunnel Interface (VTI) can be set to "tunnel mode ipsec ipv4" in which case a GRE header is not inserted in IPSec authenticated (Auth. Header) packets or in IPSec encrypted (ESP) packets.
• ipv6-6to4-tunnel-encapsulation.pcap
• ipv6-fragment-header.pcap
• ipv6-multicast-listener-report-mld-icmpv6.pcap
• ipv6-next-header-58-icmpv6.pcap
• ipv6-ndp-router-advertisement.pcap
• ipv6-prefix-delegation-dhcpv6.pcap * The "Solicit" message contains an "Option Request" for "Identity Association for Prefix Delegation", and the "Advertise" message contains the "IA Prefix" which is selected from the Prefix Delegation pool configured on the DHCPv6 Server.
• isis-authentication-cleartext.pcap
• isis-csnp-complete sequence number-pdu.pcap * In process of establishing new neighborship, IS-IS sends CSNP to inform about all LSPs currently in LSDB, sent on broadcast and on P2P links, on broadcast links only the Designated IS (DIS) router sends CSNP.
• isis-hello-message.pcap
• isis-interface-authentication-md5.pcap
• isis-ipv6-hello.pcap
• isis-ipv6-lsp-route-advertisement.pcap
• isis-level-2-lsp-summary-route.pcap
• isis-lsp-authentication-md5.pcap
• isis-lsp-external-prefix-advertisement.pcap
• isis-lsp-segment-routing.pcap * Under the section "Router Capability" the Segment Routing Capability is advertised, as well as the Algorithm and Maximum SID Depth. Under the "Extended IS reachability" and "Extended IP Reachability" sections subTLV value pairs are used to advertise further Segment Routing details such as the Adjacency-SID and the Prefix-SID.
• isis-lsp-with-mpls-traffic-engineering.pcap * Under the IS-IS "Link State Protocol Data Unit" the "Traffic Engineering Router ID" TLV is visible, and under the "Extended IS reachability" section for each "IS Neighbor" there are multiple subTLV-s added which are specific to MPLS Traffic Engineering, for example "Maximum reservable link bandwidth" and "Maximum link bandwidth".
• isis-maximum-metric.pcap * Maximum metric is displayed under "Extended IS reachability" and "IS Neighbor: 0000.0000.0003.00".
• isis-narrow-metric.pcap
• isis-overload-bit.pcap
• isis-wide-metric.pcap
• l2tpv3-encapsulation-with-vlan-tag.pcap * When L2TPv3 receives a QinQ double-tagged frame with Service VLAN 300 and Customer VLAN 100, then the SVLAN is removed during transport over the L2TPv3 tunnel, and only the CVLAN 100 remains attached, you may need to manually decode this L2TPv3 protocol capture by right clicking on a L2TPv3 data packet (not Control Message), selecting "Decode As..." and choosing "Ethernet" from the dropdown menu, you find more details in the "l2tpv3-configuration-example" blog post.
• l2tpv3-over-gre-tunnel.pcap * When a L2TPv3 pseudowire is configured over a GRE tunnel, there is the possible for IPSec protection of Layer-2 frames in transit, you may need to manually decode this L2TPv3 protocol capture by right clicking on a L2TPv3 data packet (not Control Message), selecting "Decode As..." and choosing "Ethernet" from the dropdown menu, you find more details in the "l2tpv3-configuration-example" blog post.
• l2vpn-evpn-vpws-subscriber-vlan-added.pcap * L2VPN EVPN VPWS capture of Telnet packet with subscriber VLAN ID 10 added, note that this VLAN tag can be removed with configuration on the PE routers, Wireshark packet decoding may be necessary to view this capture, right-click on packet, select "Decode As..." and choose ">Ethernet PW (with CW)" which stands for Ethernet Pseudowire with Control Word.
• l2vpn-evpn-vpws-subscriber-vlan-removed.pcap * L2VPN EVPN VPWS capture of Telnet packet with subscriber VLAN ID 10 removed, Wireshark packet decoding may be necessary to view this capture, right-click on packet, select "Decode As..." and choose "Ethernet PW (with CW)" which stands for Ethernet Pseudowire with Control Word.
• l2vpn-evpn-vpws-stretched-vlan-ospf-neighborship.pcap * This capture shows the process of establishing an OSPF neighborship over the stretched subscriber VLAN 10, which is made possible with the point-to-point Layer-2 VPN EVPN VPWS.
• ldp-authenticated-session-creation-tcp-md5.pcap * LDP authentication uses the TCP MD5 signature option, as visible in this packet capture LDP Hello messages are sent over UDP, and UDP does not include the authentication method because it is specific to TCP.
• ldp-discovery-link-and-targeted-hello.pcap * LDP uses Link Hello messages that are sent to the multicast address 224.0.0.2, and Targeted Hello messages that are sent to a defined neighbor's unicast IP address.
• ldp-implicit-and-explicit-null-label-comparison.pcap * This capture contains two Label Mapping Messages, one of them advertises the label value 3 which translates to the implicit-null label and instructs a Label Switch Router (LSR) to remove (pop) the label when forwarding traffic, meanwhile the other Label Mapping Message advertises the label value 0 which is also known as the explicit-null label.
• ldp-label-mapping-message-eompls-pseudowire-signaling.pcap * You find details under "Label Mapping Message" >> "FEC" >> "FEC Elements" >> "FEC Element 1" section which contains "FEC Element Type: PWid FEC Element (128)" and "PW Type: Ethernet Tagged Mode (0x0004)".
• lisp-encapsulated-map-request.pcap
• lisp-encapsulation-udp-tunneling.pcap
• lisp-map-register-and-reply-exchange.pcap
• lisp-map-register-eid-prefix.pcap
• lisp-map-request-by-pxtr-external-site.pcap
• mldp-ng-mvpn-downstream-label-mapping-message.pcap * Multicast LDP (mLDP) Label Mapping Message to inform about the downstream Label Switched Path (LSP) to reach a leaf PE router in Multicast VPN (mVPN), details are visible under "Label Mapping Message" section "FEC" → "FEC Elements" → "FEC Element 1" which includes the "FEC Element Type: MP2MP-down (8)".
• mldp-ng-mvpn-upstream-label-mapping-message.pcap * Multicast LDP (mLDP) Label Mapping Message to inform about the upstream Label Switched Path (LSP) to reach the root node in MP2MP core Multicast Distriburion Tree, details are visible under "Label Mapping Message" section "FEC" → "FEC Elements" → "FEC Element 1" which includes the "FEC Element Type: MP2MP-up (7)" and "Root Node Address: 4.4.4.4".
• mpls-6pe-bgp-labeled-unicast-update.pcap * Using BGP Labeled Unicast the remote site IPv6 prefix 2001:DB8:B::/64 is advertised together with an MPLS VPN service label which is assigned by a remote egress PE router.
• mpls-6pe-ipv6-traffic-forwarding.pcap
• mpls-6vpe-bgp-vpnv6-ipv6-update-message.pcap
• mpls-csc-backbone-carrier-transit-3-labels.pcap
• mpls-csc-bgp-labeled-unicast.pcap * Under "Path Attributes", in "MP_REACH_NLRI" the two "NLRI" IPv4 addresses have MPLS labels assigned. This means, BGP IPv4 address-family (not VPNv4 or EVPN RT 5) advertises MPLS VPN labels.
• mpls-encapsulated-icmp.pcap * Single MPLS label, no VPN/label stack.
• mpls-inter-as-option-a-bgp-update.pcap * BGP message exchange between ASBR PE routers with inter-AS option A, notice the BGP Update messages do not contain MPLS labels, they are IPv4 prefix updates, and not MP-BGP VPNv4 (or Labeled Unicast) updates.
• mpls-inter-as-option-ab-interconnection.pcap
• mpls-inter-as-option-b-interconnection.pcap
• mpls-inter-as-option-c-interconnection.pcap
• mpls-inter-as-option-c-label-stack.pcap * Within the local MPLS Service Provider network Inter-AS Option C uses a label stack of three labels.
• mpls-l3vpn-different-vpn-service-label.pcap * Two ping request/reply captures have the same source and destination IP address, however they belong to two different and independent customer VPNs. The MPLS VPN service label is shown under the MPLS Header and "MPLS Bottom of Label Stack: 1" section. As visible, one of the ping requests has label 1007, and the other has label 1008 assigned. These labels are assigned by the same PE router which has the two separate customer VPN/VRF tables (with label 1007 and 1008) configured using overlapping but independent IP addressing.
• mpls-l3vpn-pe-ce-eigrp-mp-bgp-update.pcap * When the PE - CE routing protocol is EIGRP, then the BGP VPNv4 route update carries additional EIGRP extended communities, these can be viewed under the "Path attributes" and "EXTENDED_COMMUNITIES" section.
• mpls-label-stack-segment-routing-transport-label.pcap * MPLS label stack contains VPN service label (aka bottom label) and a Segment Routing transport label (aka top label), the SR label is chosen from the Segment Routing Global Block (SRGB) between 16000 to 23999.
• mpls-ldp-over-traffic-engineering-tunnel-l3vpn.pcap * In an LDP-over-Traffic Engineering tunnel MPLS L3VPN design, packets transmitted in the Core Layer receive three labels, details of this Service Provider architecture are explained in the "ldp-over-mpls-te-configuration.html" blog post.
• mpls-ospf-sham-link-router-lsa.pcap * OSPF Type-1 LSA is advertised between MPLS L3VPN PE routers to establish OSPF Sham Link over the MPLS core network.
• mpls-targeted-ldp-over-mpls-te-tunnel.pcap * A Targeted LDP session can be established over an MPLS Traffic Engineering tunnel, this means the LDP message exchange is already label switched in an existing Label Switched Path (LSP) created by MPLS TE.
• mpls-te-frr-label-stack-backup-tunnel.pcap * MPLS TE FastReroute (FRR) can be configured with an LDP-over-MPLS TE design in the core layer, this means when the FRR backup tunnel is used there will be four labels assigned to traffic (MPLS L3VPN architecture).
• mpls-te-frr-local-protection-desired-rsvp.pcap * MPLS TE head-end router signals the Fast ReRoute (FRR) feature in RSVP Path Message, by setting the "Local Protection Desired" flag, this can be found under the "SESSION ATTRIBUTE" section "Flags".
• mtrace-multicast-traceroute-query-response.pcap
• mvpn-bgp-multicast-vpn-address-family-update.pcap * With Next Generation mVPN BGP can be used to translate PIM Join messages into BGP Update over the MCAST-VPN address-family, under the "Path Attribute - MP_REACH_NLRI" the NLRI is set to "Route Type: Shared Tree Join route (6)" with the contents of the original PIM Join message translated into "Shared Tree Join route (22 bytes)" section which is now VPN/VRF aware during to the Route Distinguisher and Route Target extended community.
• mvpn-bgp-pmsi-auto-discovery-route-multicast-tunnel.pcap * NG-mVPN uses BGP Intra-AS I-PMSI A-D route for Auto-Discovery of other PE routers.
• mvpn-bgp-source-active-auto-discovery-route.pcap * NG-mVPN can use the BGP Source Active A-D route (MCAST-VPN address family) which is sent when a PE router learns that a multicast source is available for a particular directly connected subscriber VPN, details are defined in RFC 6514.
• mvpn-bootstrap-pim-customer-multicast-mpls-encapsulation.pcap * This traffic belongs to an example subscriber of a Next Generation Multicast VPN (NG-mVPN) service, it is a PIM Bootstrap message sent from one customer location to a remote location over an MPLS enabled provider core network.
• mvpn-classic-rosen-draft-customer-icmp-multicast-in-gre.pcap * Multicast stream sent between customer locations is encapsulation in GRE within the mVPN provider core network (between ingress PE and egress PE), notice that the ping reply is sent with unicast and is label switched using label stack (MPLS L3VPN).
• mvpn-classic-rosen-draft-customer-pim-gre-encapsulation.pcap * PIM Bootstrap message encapsulated with GRE and transported within mVPN provider core network, it advertises the mapping between the Rendezvous Point (RP) 9.9.9.9 and the multicast group address 239.1.1.1, the RP belongs to a specific customer VRF, details can be verified under "Protocol Independent Multicast" section "PIM Options".
• mvpn-classic-rosen-draft-customer-pim-join-gre-encapsulation.pcap * Under "Protocol Independent Multicast" section it is visible that the "Upstream-neighbor:" is 2.2.2.2 which is actually a remote PE router, this message is sent for a specific customer VRF from one PE (6.6.6.6) to another PE (2.2.2.2), between two remote customer locations.
• mvpn-pim-join-mpls-encapsulation.pcap * NG-mVPN encapsulates PIM Join/Prune requests with MPLS to transport them across the service provider core, the core transport network does not have PIM or multicast enabled.
• nat64-destination-address.pcap
• native-vlan-stp-bpdu-comparison.pcap * Due to native VLAN 20, one of the PVST+ BPDU does not have a VLAN tag assigned and is 4 bytes shorter.
• ndp-ipv6-messages.pcap
• ndp-ra-default-router-preference-high.pcap
• ndp-ra-message-with-recursive-dns-server-rdnss.pcap
• ndp-ra-with-managed-address-configuration-flag-set.pcap
• ndp-router-advertisement-other-configuration-flag-set.pcap
• netflow-v5-export.pcap
• netflow-v9-export.pcap
• nhrp-purge-request-and-reply.pcap * To remove NHRP cache entries once they expire or due to reconvergence of routing topology.
• nhrp-redirect-traffic-indication-dmvpn-phase-3.pcap
• nhrp-registration-request-reply-dmvpn.pcap
• nhrp-resolution-request-reply-dmvpn.pcap
• ntp-client-mode-with-authentication.pcap
• ntp-control-query.pcap
• ntp-control-read-variables.pcap
• ntp-server-mode-clock-source-localhost.pcap
• ntp-unspecified-clock-stratum-0.pcap
• ospf-abr-link-state-update-lsu.pcap
• ospf-abr-lsa-flush-stub-area.pcap * ABR flushes inter-area prefixes in totally stub area, leaving only the default route, under each "LSA-type 3" the "LS Age" is set to 3600 seconds which is the Max Age, so the LSA will be flushed from the OSPF Database of routers that receive this LS Update.
• ospf-asbr-summary-lsa-type-4.pcap
• ospf-auth-type-2-hash.pcap * Auth type 2 (Cryptographic hash authentication) in "OSPF Header" section.
• ospf-default-route-cost.pcap
• ospf-down-bit-mpls-l3vpn-loop-avoidance.pcap * The OSPF Down Bit is set for both advertised Type-3 Summary LSAs, it can be viewed under "LSA-type 3 (Summary-LSA (IP network))" in the "Options" section "1... .... = DN: Set".
• ospf-external-lsa-metric-type-2.pcap * Under an "LSA-type 5" the "External Type = Type 2" indicates OSPF external metric type 2.
• ospf-external-metric-type-1.pcap
• ospf-forwarding-address.pcap
• ospf-hello-external-routing-option.pcap
• ospf-hello-over-gre-tunnel-multicast-address.pcap * GRE tunnel enables the use of multicast destination addresses between tunnel endpoints, in this packet capture OSPF Hello messages are sent to the 224.0.0.5 OSPF multicast address encapsulated in GRE.
• ospf-hello-packet-comparison.pcap * Normal OSPF Hello packet and OSPF Hello sent with graceful shutdown, difference visible in "OSPF Hello Packet" section "Router Priority", "Designated Router" and "Active Neighbor" fields.
• ospf-lsa-type-1-asbr.pcap
• ospf-maximum-metric-stub-router.pcap
• ospf-no-authentication-auth-type-zero.pcap * Auth type 0 in "OSPF Header" section.
• ospf-nssa-hello-packet.pcap * In the "Hello Packet" section under "Options" NSSA support is set, and "External Routing" is not set.
• ospf-nssa-no-translate-lsa.pcap * Under "LSA-type 7" in the "Options" the "(P) Propagate" bit not set.
• ospf-nssa-propagate-bit-options-lsa-type-7.pcap
• ospf-opaque-lsa-mesh-group-mpls-te-autotunnel.pcap * The Mesh Group TLV needed for MPLS Traffic Engineering (TE) Autotunnel Mesh feature is visible under the "LSA-type 10 (Opaque LSA, Area-local scope), len 40" in the "Opaque Router Information LSA" section, it is called "TE-MESH-GROUP TLV".
• ospf-opaque-lsa-type-7-and-8-segment-routing.pcap * The opaque LSA type can be found under each "LSA-type 10 (Opaque LSA, Area-local scope)". For Type-7 it is defined as "Link State ID Opaque Type: OSPFv2 Extended Prefix Opaque LSA (7)", and for Type-8 it is defined as "Link State ID Opaque Type: OSPFv2 Extended Link Opaque LSA (8)", these two LSA types are relevant for Segment Routing, Type-7 is Extended Prefix information (SR SID Label), and Type-8 is Extended Link information (SR Adjacency Label).
• ospf-opaque-lsa-type-10-mpls-traffic-engineering.pcap * Within the "LS Update Packet" and "LSA-type 10", there is the "MPLS Traffic Engineering LSA" section which contains information for MPLS TE such as "Maximum Bandwidth" and "Maximum Reservable Bandwidth".
• ospf-simple-password-authentication.pcap * Auth type 1 in "OSPF Header" section.
• ospf-summary-lsa.pcap
• ospfv3-authentication-header-ipsec.pcap * Authentication Header in IPv6 packet header.
• ospfv3-authentication-trailer-hello.pcap * Authentication Trailer added after "Hello Packet".
• ospfv3-dbd-lsu-and-ls-request-packets.pcap — In the "OSPF Header" of each of these control plane packets the "Instance ID" 10 is visible, this was manually configured to create a virtual topology within OSPFv3
• ospfv3-dbd-packet-authentication-trailer.pcap
• ospfv3-forwarding-address.pcap * Assigned to Type-5 LSA.
• ospfv3-forwarding-address-absent.pcap * Under "LSA-type 5" in "Flags".
• ospfv3-hello-packet-ipv6-address-family.pcap
• ospfv3-ipv4-hello.pcap * Under "OSPF Header" the "Instance ID" displays that "IPv4 unicast AF" (address-family) is used.
• ospfv3-lsa-type-8-and-type-9.pcap
• pim-assert-and-prune.pcap * When a multicast packet is received on a PIM router's Outgoing Interface List (OIL), then it will automatically reply with an Assert message, and a Prune message is also sent.
• pim-bidirectional-bootstrap-message-rp-address.pcap * Under the "PIM Options" section about "Group 0: 239.0.0.1/32" the "Bidirectional PIM" Flag is set.
• pim-designated-forwarder-election-offer-and-winner.pcap * Bidirectional PIM uses the Designated Forwarder (DF) election messages, this capture contains a DF election Offer, and a DF election Winner packet, under "PIM Options" there is a "DF Metric Preference" and a "Metric" value which are actually inherited from the IGP routing protocol (in this case EIGRP).
• pim-graft-message.pcap
• pim-ipv6-hello.pcap
• pim-ipv6-sparse-mode-bootstrap.pcap
• pim-join-and-prune-message.pcap * This capture contains two PIM packets, one is a PIM Join, and the other is a PIM Prune message, the message type can be verified under the "PIM Options" "Group 0" section which separately lists the "Num Joins" and "Num Prunes" for each individual multicast group address.
• pim-join-prune-override.pcap * PIM Join request sent during Prune Override mechanism (PIM Dense Mode), in the "PIM Options" section, under "Num Joins: 1" none of the flags are set (no Sparse, no Rendezvous Point Tree).
• pim-msdp-multicast-source-discovery-protocol-peer-relationship.pcap * MSDP peering between two Rendezvous Points (RP) uses TCP port 639, MSDP uses Keepalive to verify peering state.
• pim-msdp-source-active.pcap
• pim-prune-message.pcap
• pim-sparse-mode-auto-rp-announcement-and-mapping.pcap
• pim-sparse-mode-bootstrap-and-candidate-rp-advertisement.pcap
• pim-sparse-mode-bootstrap-with-group-to-rp-mapping.pcap
• pim-sparse-mode-join-comparison-spt-switchover.pcap * First packet is sent to Rendezvous Point address indicated with "IP address: 6.6.6.6/32 (SWR)", second packet is sent during Shortest Path Tree (SPT) switchover and is directly sent from the LHR towards the multicast source address indicated with "IP address: 192.168.1.1/32 (S)".
• pim-sparse-mode-join-message.pcap
• pim-sparse-mode-register-and-register-stop.pcap
• qinq-double-tagged-frame.pcap
• qinq-gbpt-layer-2-protocol-tunneling-cdp.pcap * GBPT enables tunneling CDP and LLDP frames across a Q-in-Q service provider core network by assigning the Service VLAN.
• radius-accounting-request.pcap
• radius-authentication.pcap
• rsvp-error-message-routing-bad-loose-node.pcap * Error code and value are visible under "ERROR: IPv4, Error code: Routing Error" section, details for RSVP error codes described in RFC 3209.
• rsvp-hello-request-and-acknowledgement.pcap
• rsvp-path-message-mpls-traffic-engineering.pcap
• rsvp-path-message-with-strict-and-loose-ero.pcap * To establish an interarea MPLS Traffic Engineering tunnel RSVP Strict and Loose ERO (Explicit Route Object) needs to be defined on PE routers, this is visible in the packet capture under the "Resource ReserVation Protocol (RSVP)", "EXPLICIT ROUTE" section which contains "IPv4 Subobject" with either "Strict" or "Loose" designation.
• rsvp-path-tear-message-mpls-traffic-engineering.pcap
• rsvp-resv-message-mpls-traffic-engineering.pcap
• rsvp-resv-tear-mpls-traffic-engineering.pcap
• scp-file-transfer-over-ssh.pcap
• segment-routing-traffic-engineering-sid-list.pcap
• smtp-email-transfer.pcap
• smtp-email-transfer-over-gre.pcap
• snmpv2-inform-request.pcap
• snmpv2-get-request.pcap
• snmpv2-getnext-request.pcap
• snmp-response-no-such-object.pcap
• snmpv2-trap-message.pcap
• snmpv3-auth-priv.pcap
• snmpv3-auth-nopriv.pcap
• snmpv3-encrypted-pdu.pcap
• snmpv3-getbulk-request.pcap
• snmpv3-noauth-nopriv.pcap
• snmpv3-trap-message.pcap
• ssh-protocol.pcap
• stp-multiple-spanning-tree-mst-bpdu.pcap
• stp-pathcost-method-long.pcap * Next to "Root Path Cost" the value 450 000 is displayed.
• stp-per-vlan-pvst-bpdu.pcap
• stp-topology-change-notification.pcap
• syslog-message-debug.pcap
• syslog-notice-message-device-reload.pcap
• telnet-ipv6-login-over-segment-routing-mpls-l3vpn.pcap
• telnet-ipv6-login-sequence.pcap
• telnet-ipv6-with-mpls-label-stack.pcap
• tftp-file-transfer-protocol-download.pcap
• tftp-file-transfer-protocol-upload.pcap
• unified-mpls-label-stack.pcap
• urpf-silently-drops-traffic.pcap
• vpls-arp-request-reply-mpls-label-stack.pcap * You may need to decode the capture by right-clicking on a packet, choosing "Decode As..." and selecting "Ethernet PW (with CW)" from the dropdown list, it stands for "Ethernet Pseudowire with Control Word".
• vpls-autodiscovery-l2vpn-bgp-update.pcap * BGP can be used with VPLS for Autodiscovery and Pseudowire Signaling, in this BGP Update under the "Path Attribute - MP_REACH_NLRI" there is information about the remote VPLS PE router.
• vpls-l2vpn-arp-and-icmp.pcap * ARP exchange and ICMP over MPLS L2VPN with VPLS, notice the VLAN 10 tag is added to each packet, this is because two sites have a stretched VLAN 10 between them, in Wireshark the packets may need to be decoded by right clicking on a packet and selecting "Decode As..." and choosing "Ethernet PW (no CW)" from the dropdown list, it stands for Ethernet Pseudowire no Control Word.
• vpls-ldp-label-mapping-message-pseudowire-signaling.pcap * You find details under "Label Mapping Message" >> "FEC" >> "FEC Elements" >> "FEC Element 1" section which includes "Generalized PWid FEC Element (129)" and "PW Type: Ethernet (0x0005)".
• vpls-mpls-encapsulation-label-stack.pcap * You may need to decode the captures by right-clicking on each packet, choosing "Decode As..." and selecting "Ethernet PW (with CW)" from the dropdown list, it stands for "Ethernet Pseudowire with Control Word".
• vrf-aware-dhcp-vpn-suboption.pcap * DHCP Option 82 and three suboptions are added to VRF-aware DHCP packets that are transported between the DHCP Relay Agent and the DHCP Server, these suboptions identify the specific VRF that is assigned to the subnet where the DHCP-client device is located.
• vrrp-ipv4-advertisement-announcement.pcap
• vrrp-ipv6-advertisement.pcap
• vrrp-ipv6-state-change-process-ndp-icmpv6.pcap
• vxlan-arp-encapsulation.pcap
• vxlan-with-multicast-pim-register-message.pcap