Archive for the ‘header’ tag
Frame Relay Notes – LMI, Headers, and Encapsulation
- Manages link between the router and frame relay switch
- Routers send Status Enquiry to the switch
- The switch responds with a Status message informing the router of the DLCIs available
- Serves as a keepalive
- Default keepalive is 10 seconds, 3 misses is failed
- Three types
- cisco <- default
- ansi (Annex D)
- q933a
R1(config)#interface s1/0 R1(config-if)#frame-relay lmi-type ansi
- Link Access Procedure for Frame-mode Bearer Services (LAPF) is the first header
- Includes DLCI, DE, FECN, BECN
- To be read by the frame relay switch
- Frame relay encapsulation header is next
- To be read by the router on the other end of the VC
- Two types
- cisco : proprietary <- default
- ietf : IETF RFC 2427
R1(config)#interface s1/0 R1(config-if)#frame-relay encapsulation ietf <- for all DLCIs - or - R1(config-if)#frame-relay interface-dlci 100 ietf <- for specific DLCIs - or - R1(config-if)#frame-relay map ip 10.0.0.1 ietf <- for specific DLCis
Wireshark and EtherIP Packets
I got a call from our Systems and Security guys today to talk about a Wireshark capture they had done from a user VLAN. They had noticed two frames that were destined for some seemingly random host in the same network as they were in, but the source and destination IP addresses reported by Wireshark made no sense. The frames were from a web server to an IP address on our wireless network. The web server is on the other side of the firewall, and the wireless network is on the other side of the controller; there was no reason at all that a packet with that source and destination would show up here.
We took a closer look and figured out that Wireshark was showing us the wrong destination and source IPs for the frame. What we were actually seeing was a pair of frames that were part of an EtherIP tunnel from a wireless the controller on the other side of campus to the local AP. If you’ve ever seen an EtherIP frame, you know it can be confusing. A full Ethernet frame is shoved into an EtherIP packet to be sent via IP to the destination. Of course, the new packet then gets put into an Ethernet frame and put on the wire. When all is said and done, you wind up with both an inner and an outer set of IP and MAC addresses among the 8 different “headers” that Wireshark shows. Wireshark was reporting the inner IP addresses in the packet list, so that was throwing everybody off. A government-quality screen cap is below for your pleasure.
Once we figured out which addresses the switches and routers were using, it was easy to figure out that there were only 2 frames showing up destined for a MAC that doesn’t see much action. The CAM table entry had timed out for that guy, so the switch had flooded the unknown unicast frame. After the AP responded, we all lived happily ever after.
I love calls that get the brain working. It just goes to show that you have to look at the packets closely sometimes to figure out what’s going on.
Network Protocol Overhead
Here are some packet overhead numbers for a few popular protocols to help with doing bandwidth requirement calculations. This may be another add-as-we-go post, so please comment with additions or corrections.
Ethernet : 20 bytes
Frame Relay : 4 – 6 bytes
PPP : 6 bytes
MLPPP: 10 bytes
MPLS : 4 bytes
IP : 20 bytes
TCP : 20+ bytes
UDP : 8 bytes
GRE: 4 – 20+ bytesIPSec : 50 – 57 bytes
ESP : 20+ bytes
AH : 16+ bytes
L2TP : 24 bytes
RTP : 12 bytesBonus: A voice packet is always 40 bytes + data link since it will always (?) use RTP + UDP + IP.
Sources
CCNA Voice Official Exam Certification Guide (640-460 IIUC)
Encapsulating Security Payload