BGP Route Reflectors (RRs) defined in RFC 1966 reduces the need for iBGP peers to be in a full mesh, by relaxing the standard rule where iBGP routes are not sent to iBGP peers.

A designated Route Reflector router treats all neighbour routers as one of 3 types, clients, non-clients and eBGP. The relaxed rules for Route Reflectors are;

• Updates received from a client are sent to all clients & non-clients
• Updates received from a non-client are sent only to clients
• Updates received from eBGP peers are sent to all clients & non-clients

A Route Reflector and its clients combine to form a Route Reflector cluster, a BGP design could have multiple clusters or a cluster with multiple Route Reflectors. If muliple clusters exist then one Route Reflector per cluster must be peered directly with a Route Reflector in another cluster, although usually the Route Reflectors from all clusters peer directly.

As one of the loop prevention rules of BGP has been removed (never send iBGP learned routes to iBGP peers) it is possible that loops could form. To prevent this BGP route reflectors only reflect the best routes, also there are 2 optional non-transitive BGP attributes which further prevent looping these are;

ORIGINATOR_ID, this is a 4 byte attribute which contains the Router ID of the first iBGP peer which originated the route into the AS. Route Reflectors never send an update to the router specified in the ORIGINATOR_ID

CLUSTER_LIST, is list of the cluster IDs which the update has been passed through, each Route Reflector will add its own cluster ID to the list before sending an update. If a Route Reflector sees its own cluster ID in the list it ignores the update.

I was planning to write a nice technical post on IPv6 migration techniques but I had a few cans of red bull and my mind has gone a wander.

Whenever IPv6 is mentioned it always causes a big rift in opinions, alot of people say that IPv4 will be totally deleted in 3 years +/-6months, according to RIPE who are responsible for IP & BGP AS allocation Europe. And the next Google’s and startups won’t be able to get IPv4 space and due to its rarity many people are concerned its going to become a commodity where companies will be bought/sold for their address space, there could even a potential black market in IPv4 space? Emerging countries such as Africa & China which are coming online will need huge allocations of address space to fulfill their needs, and mobile devices such as iPhones and internet devices everywhere becoming more popular there is a growing need. With NAT/PAT apparently harming innovation as there is a need for end to end addressing transparency, there is a clear need for more address.

But is IPv6 the answer?

Whenever IPv6 is mentioned it always causes a big rift in opinions, some people simply don’t believe that every host on the internet will ever change its TCP/IP stack for IPv6 as that change is a once in a lifetime opportunity and there is not a viable business reason to do so at the moment.

Vince Fuller who is a Senior Technical Consultant at Cisco Systems discussed recently that IPv6 is not the complete answer as although it solves the address limitations it does not solve the scalability issues issues we will eventually face with massive routing tables. I was lucky enough to speak to him at RIPE 56 and heard his presentation on a possible solution to some of the issues with Locater Id Separation (LISP).

Its going to be really interesting in the next few years to watch IPv4 “hit the wall”, and to see if it will be adopted and how long it will take, I wonder if it will become the chicken and egg conundrum of what will come first applications & websites or the user base?

I remember when I first saw Storm Control in a config and thought “woah, whats that looks really confusing”, but really its pretty simple stuff.

We use storm control to rate limit layer 2 traffic, this helps us prevent a subnet from being flooded with broadcasts, multicasts which would adversely affect the performance of the entire subnet. Storm Control can only be configured on physical interfaces and will not work on subinterfaces, or an LACP/PAGP interface.

Configuration

The first command shown limits the broadcast to 200pps, and if this limit is reached will not forward any more broadcasts until this is reduced to 150pps
(config-if)#storm-control broadcast level pps 200 150

Multicast and unicast traffic can also be limited, the maximum level can also be entered as a percentage instead of pps, in the example below multicasts can use up to 5% of the interface bandwidth, and once that limit is reach no more multicasts will be forwarded until it drops to 4.5% of the total interface bandwidth
(config-if)#storm-control multicast level 5 4.5

In the final example unicast is limited to 80% of the interface bandwidth but a second value is not specified, this causes all unicast to be forwarded up to 80% of the bandwidth and it does not force the traffic to wait until it drops below a second level
(config-if)#storm-control unicast level 80

The default response for storm control is the drop packets which are over the rate limit, and create a syslog message, we can also generate a SNMP trap with the command
(config-if)#storm-control action trap

The show commands for this are also really easy, I will paste the output of this when I am home
(config-if)#show storm-control port [unicast|broadcast|multicast]

A recent example of a Layer 2 attack happening in the real world was where the popular hacking tool website Metasploit was taken down, the attacker who had a server in the same subnet as the Metasploit web server would send ARP messages saying that the MAC of the metasploit web server was actually on the attackers server. The actual MetaSploit webserver was up and running fine but any user visiting the website would see the attackers “victory” message instead of the actual Metasploit website. This attacked was not resolved but Dynamic Arp Inspection but its a cool example of what it can prevent.

There are many other attacks which abuse ARP messages and they commonly result in DOS or man in the middle attacks. Dynamic ARP Inspection (DAI) is a great method of preventing ARP based attacks.

If DAI is deployed on a switch it will examine ARP messages on every untrusted port and discard inappropriate ones, it does not examine ARPs on trusted ports. End stations should be configured as untrusted and connections to other switches & network devices should always be trusted, otherwise possibly valid ARP messages could be discarded.

The following are steps which DAI will decide whether to discard a packet on an untrusted port. Only step 1 is used by default steps 2 to 4 require extra configuration.

1 – If an ARP message states an IP address which has not been assigned via DHCP to that port the ARP is dropped.

2 – The ARP is checked against a staic list of IP/MACs and if it doesnt match the ARP is dropped

3 – An ARP reply should have the source MAC and the MAC in the message the same, if they are different the ARP is dropped. Also the destination MAC and MAC target are compared, if they are different the ARP is dropped

4 – Unusual IP addresses can be also filtered such as the subnet addresses, broadcast addresses and multicast addresses.

Configuration

DAI is enabled per VLAN with the following command;
ip arp inspection vlan vlan-range

All ports default to become trusted ports so to start the inspection of ARPs ports must be configured as untrusted with the interface command
no ip arp inspection trust

Option 2 in the list above where static IP/MAC lists can be checked with the following command
ip arp inspection filter arp-acl-name vlan vlan-range [static]

Steps 3 & 4 in the list above are not checked by default but they can be with the command
ip arp inspection validate {[src-mac] [dst-mac] [ip]}

The maximum rate of ARPs can also be limited to prevent DoS attacks with the command
ip arp inspection limit {rate pps [burst interval seconds] | none}

The address range of 233.0.0.0/8 is reserved for GLOP addressing, it was originally defined in RFC 2770 (superseded by RFC 3180) the RFC authors David Meyer & Peter Lothberg unfortunately didn’t define what GLOP stands for.

The cool thing about GLOP addressing is that every ASN has its own defined range for multicast. The first octet is always 224, and the 2nd and 3rd octets should be be the uniquely assigned ASN, and the final octet is locally administered. Therefore every ASN is provided with a pool of 256 addresses which they can use for internet multicast.

The restrictions of GLOP addressing only works with 2 byte ASNs, each ASN only has a pool of 256, also not having an acroynm or meaning for GLOP will bug me so im bound to be up all night thinking of acronyms of GLOP.

I was reading about traffic shaping & policing and the acronyms in the book they were as clear as mud, but now Ive written them down and understand them they are really really simple. I put a few formulas on for them aswell, but havnt checked them so please correct me if im wrong, oh and I have presumed that you are attempting to traffic shape to the CIR.

Tc – This is a time interval in milliseconds when a Committed Burst (Bc) can get sent. Usually Tc = Bc / CIR

Bc – Committed Burst this is the amount of data in bits which can bet sent every Tc. Usually Bc = CIR / Tc

Be – Excess Burst is the number of bits the Bc can be exceed by if no data has been sent if no data has been sent in previous Tcs. EDIT: As commented by Jeriel Atienza the formula is Be = (Ar – CIR) * Tc/1000

CIR – Committed Information Rate this is the bandwidth of a link or VC in bps which the Service Provider guarantees to provide. Quite often the CIR is lower than the full capabilities of a link which is the main reason why traffic should be shaped & policed. CIR = Bc * Tc

Shaped Rate – This is the rate of the traffic which is being shaped in bps, it normally matches the CIR. Usually CIR = Shaped Rate!

If anybody asks me for advice on how to pass the CCNA or any of the CCNP modules I would always say to book the exam and work towards that date. Otherwise you just end up casually reading the books meandering around the topics and the next thing you know its 6 months later and your playing computer games all the time and have forgotten about it.

So I took a bit of my own advice and booked the exam, I admittedly was also swayed by Brandon posting a coupon (which worked when I used it!) for 20% off all Cisco written exams. I have booked the exam for the 26th of September, as it fits well into my timetable and I should be able to totally finish of the CCIE Routing & Switching Exam Certification Guide 3rd Edition by Cisco Press at least a month before the date, this provides me with enough time for me to look at some secondary material and do lots of those Boson test questions that came with the book to find my weak spots.

Even with 20% off its still blooming expensive!

Total Purchases: GBP 172.00
Discounts: GBP 34.40
Tax: GBP 24.08
Amount Paid: GBP 161.68

WRED is a method of congestion avoidance which manages and slows down TCP flows to prevent them from congesting a link.

Tail Drops are packets which are dropped when the queues are full, if trail drops occur then multiple packets usually get dropped this causes TCP to slow down considerably. It is more efficient to discard fewer packets before the queue gets full rather than have packets being tail dropped, WRED achieves this.

WRED looks at the average queue depth and compares this to the minimum & maximum queue depth. If the average queue depth stays below the minimum queue depth no packets will be dropped, but likewise if it goes past the maximum queue depth all packets will be dropped, this is called full drop and is different to tail drop as the buffers are not full but it works in a similar way. If the average queue depth is between the minimum & maximum queue depths then it will drop a percentage of packets from 0 to a maximum percent. The maximum percent to drop is defined in the Mark Probability Denominator (MPD), the simple formula is;

Drop % = 1 / MPD

For IPP 0 traffic the MPD defaults to 10, which results in a maximum of 10% (10% = 1 / 10) of the traffic being dropped between the minimum & maximum threshold, remember that  if the average queue depth exceeds the the maximum threshold it will always drop 100% of the traffic. I have created a graph showing this below;

Not all queuing methods support WRED so it can only be configured on a physical interface (with FIFO), on a non LLQ class inside a CBWFQ policy map, or on an ATM VC.

WRED is configured on a physical interface or in a class within a policy map with the random-detect command. By default WRED will only look at IPP and not DSCP but we can use the random-detect dscp-based command to tell WRED to look at DSCP instead of IPP.
By default WRED will also respect the drop probability set in the DSCP value for Assured Forwarding by changing the default minimum drop threshold depending upon the drop proabibiltiy.

The WRED settings for each IPP or DSCP value can be changed with either of the following commands;
Random-detect precedence precedence-value min-threshold max-threshold [mark-probability-denominator]
Random-detect dscp dscp-value min-threshold max-threshold [mark-probability-denominator]

We can also change part of the WRED calculation which changes the formula for the rolling average queue depth, this is called the exponential weighting constant and changed with the command random-detect exponential weighting-constant exponent. Setting it to a high value makes the changing average move slower, and setting it to a low value makes it a quicker changing value, its not recommended that this is changed.