BGP NOTES

BGP BEST PATH SELECTION PREREQUISITES

-next hop value must be in the routing table
    prevents route recursion failure
-synchronization rule must be met or disabled
    legacy black-hole prevention technique
-as-path must not contain local-as
    normal ebgp loop prevention
    can be disabled with allow-as in
-first asn in path must be neighbors ASN
    bgp enforce-first-as command



1-PRE-BESTPATH COMMUNITY
WEIGHT
    cisco propietary
    locally significant
    higher value is preferred

LOCAL PREFERENCE
    higher value preferred
    not advertised to ebgp peers
    carried through confederation ebgp

LOCALLY ORIGINATED
    locally originated gets Weight of 32768

AS_PATH
    smaller length is preferred

ORIGIN
    IGP is over EGP over incomplete
    status codes I > E > ?

MED
    smaller values is preferred
    only compared when peering to the same provider by default


EBGP over IBGP
    if you learned it via EBGP it´s not your prefix

IGP Metric to Next-Hop
    can use multi-path if all equal after this step
    Hidden commands to allow multipath if AS_PATH is not the same (has to be same length)
    bgp bestpath as-path multipath-relax

TIE BREAKERS
    oldest
    lowest RID
    Shortest CLuster List
    Lowest Neighbor Address

Best Path Slection Exceptions
AS_PATH
    bgp bestpath as-path ignore

MED
    bgp always-compare-med
    bgp bestpath med-confed
        - compares MED for routes locally originated in the confederation
    bgp bestpath med missing-as-worst
        -Assign MED of 4,294,967,294 to NULL MED
    bgp deterministic med
        -compare MED against all possible paths


IGP METRIC
    bgp nestpath igp-metric ignore - Introduced IOS-XE 3.4S

ROUTER_ID   
    No bgp bestpath compare-routerid

ATTRIBUTES TO INFLUENCE OUTBOUND PATH SELECTION

WEIGHT & LOCAL PREFERENCE
    -Set Inbound
    -Affects Outbound traffic


ATTRIBUTES TO INFLUENCE UNBOUND PATH SELECTION

AS_PATH & MED
    -Set outbound
    -Affects inbound traffic

CCIE Inspirational video

I ran into this video and wanted to pass it along in case you have not watched it yet.

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.