RFCs CCIE V5

Below you will find some  RFCs related to our CCIE studies.

 L3 technologies

• Private Addressing      1118
• NAT                             1631

Multicast

• IGMPv1                    1112
• IGMPv2                    2236
• RTP                           1889

Out of order packets

IP protocol by nature does not guarantee packet delivery in the order in which they were sent, this is a common behavior since we can’t control the entire path of a packet when traversing different carrier’s networks/Paths.

In principle, applications that use a transport protocol such as TCP or SCTP don't have to worry about packet reordering, because the transport protocol is responsible for reassembling the byte stream  into the original ordering. However, reordering can have a severe performance impact on some implementations of TCP.

Real-time media applications such as audio/video conferencing tools often experience problems when run over networks that reorder packets. This is somewhat remarkable in that all of these applications have jitter buffers to eliminate the effects of delay variation on the real-time media streams.

Notes: Packet reordering can lead to retransmissions, delays, and even connection timeouts.

Unicast flooding

It refers to the unintentional behavior of a switch treating a unicast packet as a broadcast packet; The cause of flooding is that the destination MAC address of the packet is not in the L2 forwarding table of the switch. Normally occurs when the router needs to deliver a packet; it has an ARP entry for a destination host, but the switch has no CAM entry.   The result is a packet that needs to be flooded to all of the ports in the VLAN In order to locate that MAC address port/VLAN.

Common reasons for destination MAC address not being known to the switch:

Cause 1: Asymmetric Routing.

With asymmetric routing, transmit and receive packets follow different paths between a host and the peer with which it communicates, at some point in the packet delivery path a Switch may not have that MAC address destination on its CAM table and would need to flood the frame in order to discover which port/MAC address is.

Cause 2: Spanning-Tree Protocol Topology Changes.

Since TCNs are triggered by a port that is transitioning to or from the forwarding state we may remember that what TCN does is to age out the CAM table in order to relearn the Active MAC address, this is not a big deal until TCNs are occurring repeatedly with short intervals. The switches will constantly be fast-aging their forwarding tables so flooding will be nearly constant.

Normally, a TCN is rare in a well-configured network. When the port on a switch goes up or down, there is eventually a TCN once the STP state of the port is changing to or from forwarding. When the port is flapping, repetitive TCNs and flooding occurs.

Cause 3: Forwarding Table Overflow.

Another possible cause of flooding can be overflow of the switch forwarding table. In this case, new addresses cannot be learned and packets destined to such addresses are flooded until some space becomes available in the forwarding table. New addresses will then be learned. This is possible but rare, since most modern switches have large enough forwarding tables to accommodate MAC addresses for most designs.

By default unkown unicast traffic is flooded to all Layer 2 ports in a Vlan. We can use UUFB and UMFB, features to prevent or limit this traffic.

The UUFB and UMFB features block unknown unicast and multicast traffic flooding at a specific port, only permitting egress traffic with MAC addresses that are known to exist on the port. The UUFB and UMFB features are supported on all ports that are configured with the switchport command, including private VLAN (PVLAN) ports.

Router(config-if)# switchport    --> Configures the port for Layer 2 switching.

Router(config-if)# switchport block {unicast | multicast} -->Enables unknown unicast or multicast flood blocking on the port.

Note: Enter the switchport block multicast command only on ports where all unknown multicast flooded traffic needs to be completely blocked. UMFB disrupts protocols that make use of local subnetwork multicast control groups in the 224.0.0.0/24 range, for example:

•ARP

•IPv6 neighbor discovery (IPv6 ND)

•Network Time Protocol (NTP)

Do not enter this command on nonreceiver (router) ports or host ports that rely on dynamic ARP. Use IGMP snooping or other rate-limiting options to restrict, rather than completely block, unknown multicast flooded traffic.

Impact of micro burst

Microbursts are patterns or spikes of traffic that take place in a relatively short time interval(generally sub-second) causing network interfaces to temporarily become oversubscribed and DROP traffic. While bursty traffic is fairly common in networks and in most cases is handled by buffers, in some cases the spike in traffic is more than the buffer and interface can handle. 

 Typical monitoring systems pull interface traffic statistics every one or five minutes by default.  In most cases this gives you a good view into what is going on in your network on the interface level for any traffic patterns that are relatively consistent.  Unfortunately this doesn’t allow you to see bursty traffic that occurs in any short time interval less than the one you are graphing.

The first place you might notice you are experiencing bursty traffic is in the interface statistics on your switch under “Total Output Drops”.

R2#sh int f0/0 | inc Input

 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 7228

If you are seeing output drops increment, but the overall traffic utilization of that interface is otherwise low, you are most likely experiencing some type of bursty traffic.

Asymmetric routing

Asymmetric routing in general is a normal, but unwanted situation in an IP network. Asymmetric routing is a situation where for one reason or another packets flowing in i.e. TCP connections flow through different routes to different directions. As a rough example: Host A and B located in different continents are communicating through a TCP connection. Segments sent from host A to host B reach the destination through WAN LINK X link but segments sent from B to A reach the destination through WAN LINK Y link.

ROUTERA----->WAN LINK X----->ROUTERB  Going  path.
ROUTERB----->WAN LINK Y----->ROUTERA  Return path.

IPv4 and IPv6 fragmentation

IPv4 Fragmentation-

When an IPv4 packet is larger than the network's MTU(default to 1500), and the DF bit within the IP header is clear the packet will be fragmented into smaller pieces so it can be sent to the other end. The maximum size of each piece is the MTU minus the IP header size (20 bytes minimum; 60 bytes maximum).

Fragmentation has a negative impact on router's performance and it should be avoided when possible.

IPv6 Fragmentation-

As opposed to IPv4, fragmentation in IPv6 is performed by the IPv6 enabled nodes not by the routers along the path. If an intermediate node such as a router receives an IPv6 packet that needs to be fragmented, it will discard the packet and send an ICMPv6 Packet Too Big error message back to the source as routers will not attempt to perform fragmentation unless they are the source of the IPv6 packet.

IP MTU

IP Maximum Transmission Unit (MTU)

IPv4 requires that every node must be able to forward an IP packet of 68 bytes without any further fragmentation. This is because an IPv4 header can be as large as 60 bytes in length or have a minimum fragment size of 8 bytes. Every IPv4 node that is the final destination of the IPv4 packet must be able to receive an IPv4 packet of a minimum size of 576 bytes, which can be all or fragments of the original packet.

IPv6 requires that every link have a minimum MTU of 1280 bytes, with a recommended MTU of 1500 bytes, compared to 68 bytes in IPv4. It is recommended that IPv6 devices perform Path Discovery MTU to avoid fragmentation.