Packet Captures

Simple password authentication in ospf in which we can see password in clear text.
Also the auth type is also specified in the packet which is simple password.
I have also found a very interesting article regarding md5 auth mistakes made by many network engineers the link of which is below.

http://packetlife.net/blog/2010/jun/1/ospfv2-authentication-confusion/

DTLS handshake with one application data packet.
Authentication with server certificate only.

NULL encryption is used to demonstrate the transmission of "TESTING"

This is a packet capture from a SonicWall. We were troubleshooting DHCP packet flows. The SonicWall saw the DHCP Discover and Sent an Offer. We never saw the DHCP acknowledgement. In the adjacent core stacked switching we were running "debug ip dhcp server packets" we only saw discover packets from IP phones up to the SonicWall. For some reason the SonicWall could not let any other DHCP packets through or out of it INSIDE (LAN) interface. Even if we put an ANY-ANY ALC for that interface. We ended up having to replace the SonicWall and upload the configuration from the old SonicWall to the new one.

-Slaingod

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

Router "B" (AS 2) at 172.16.3.2 does not support 4-byte AS numbers, while router "A" (AS 10.1 / 655361) at 172.16.3.1 does.

Router "A" receives an UPDATE for the 40.0.0.0/8 subnet from an external router ("D") in the AS 40.1 / 2621441 (not shown), and it forwards it to "B" (pkt n. 2): AS_PATH contains "23456 23456" (the first stands for AS 10.1, the second for the originating AS 40.1), but NEW_AS_PATH contains the real 4-byte AS numbers.

At pkt n. 3 "B" receives the same subnet directly from "D" and sends it to "A", including the original NEW_AS_PATH attribute previously appended by "D".