BGPv4 Overview

This is a quick overview of the BGP-4 (Border Gateway Protocol version 4) routing protocol. BGP is the glue of the Internet - it is what allows all the ISPs to exchange routing information between each other. The protocol is, by design, quite slow to converge, but is also very versatile due to the use of various path attributes.

BGP is an application that allows for exchanging large amounts of routing information between manually configured peers. It works on top of existing network infrastructure and is therefore rarely used on its own.
I don't work much with BGP in my current position, but when I do it is usually in a setup, where a site needs to have redundant connections inbound from the Internet with multiple Internet Service Providers. If you have your own Autonomous System Number (ASN), this is pretty much the only proper way to ensure that the Internet can reach your IP subnets at all times. However, BGP can be used even if you don't own your own set of IP addresses. An ISP is probably more than willing to lend out some of its addresses for a fee and that can in turn be exchanged using BGP from your enterprise to the ISP - this may, however, make multihoming across multiple ISP's somewhat problematic.

BGP is huge and has so many features that this post will only just cover the very basics of the protocol. Bare in mind that with all these features and complexity, BGP also brings along the most flexibility and scalability, when compared to any other routing protocol.

Now on to the hard facts of BGP-4.

• Open standard based on RFC 4271 (this is the base RFC for BGP-4, but there are other RFCs that add functionality to the protocol, which are not part of this RFC)
• Classless
• Path Vector Routing Protocol
• Uses TCP port 179
• Exchanges incremental triggered updates
• Uses a keep-alive mechanism between peers
• Uses prefix attributes for routing decisions
• Mainly used to exchange routing information between autonomous systems (AS)
• BGP Peerings are manually configured (no automatic peering mechanism)
• A BGP peering is either internal (iBGP) or external (eBGP)
• iBGP peers are peers with the same AS numbers
• eBGP peers are peers with differing AS numbers
• Supports authentication of peers using TCP Option 19 (MD5 hash)
• Administrative distances
• Internal: 200
• External: 20
• Loop prevention mechanisms
• eBGP: if an update is received containing its own AS number - that is a loop and is therefore dropped.
• iBGP: routes received from an iBGP peer is not forwarded to any iBGP peer - only to eBGP peers. This is a form of split-horizon natively implemented in the iBGP process.

BGP Message Types

There are four different types of BGP messages: open, update, notification and keep-alive.

Open message is used to initiate communication with a new peer and negotiate stuff like hold-timers and other optional capabilities.

Update message is used to both advertise and withdraw network prefixes.

Notification message is used to tear down an active peer and inform of the reason for the closure.

Keep-alive message is used to maintain the peering and are sent within the agreed holdtime to ensure the peers do not expire.

BGP Best Path Selection

BGP best path is the sequence in which BGP looks for tie-breakers, when comparing multiple paths to the same prefix. Most tie-breakers are found within the first 4 entries, which I will list below.

1. Weight - Highest weight breaks the tie
2. Local Preference - Highest local_pref breaks the tie
3. Originate - local preferred
4. AS Path - shortest AS path preferred

As final tie-breakers, BGP will use the router-id - and if the router-id is the same, the route received from the lowest neighbor address is used as the final-final tie-breaker... if they are still the same you have broken the laws of the universe (much like dividing by 0).

Cisco has a very detailed document on the matter here: http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html

It is worth mention, that there is considered to be step 0, that has BGP evaluate the reachability of the next-hop address - making it disregard any NLRI entry with an unreachable next-hop router.

BGP four-octet AS number space

Originally, the AS number was a 2-byte field allowing for AS ranges of 1-64511 for public ASNs and 64512-65535 for private ASNs. With the RFC 4893, the issue of ASN shortage was resolved by making this a 4-byte field and Cisco added support for this beginning with IOS 12.4(24)T.

Cisco supports two types of four-octet notation: normal and dot notation. This has no bearing on the AS number sent to neighbors - this is only the format presented in the config output. Use the command bgp asnotation dot under the router bgp process to turn on the dot notation.

The normal notation goes from 1 to 4294967295 and the dot notation goes from 1.0 to 65535.65535. The dot notation is (for some) easier to read and remember - but bear in mind that this is only layout - it has no bearing on the actual AS number used and advertised by the BGP process.

For a more in-depth information on all things BGP, Cisco's documentation site is gold: http://www.cisco.com/c/en/us/tech/ip/border-gateway-protocol-bgp/index.html

OSPFv2 Overview

This is a quick overview of the OSPF (Open Shortest Path First) routing protocol. The version of OSPF focused on in this post will be the IPv4 OSPFv2 variant. I will do another post on OSPFv3, which is OSPF for IPv6. This post will be somewhat Cisco centric (again, reading up for the CCIE exam) and so some of the points below may not be directly from the RFC, but more in the adaptation of OSPFv2 in Cisco gear.

• Open standard based on RFC 2328 (2328 is the current OSPFv2 specification, but there are many RFCs that add different functionality to OSPF apart from what is described in 2328)
• Classless
• Link-State routing protocol
• Uses IP protocol 89
• Sends Hello messages
• Used to form neighbor relationships
• Used as a keepalive between neighbors
• Default Hello interval is 10 seconds
• Default on NBMA and point-to-multipoint NBMA links is 30 seconds
• Uses a Dead timer 
• Default Dead timer is 4 times the Hello timer
• Sends partial and full updates
• Updates are triggered
• Updates will be sent after 30 minutes by default (half the MaxAge timer)
• Uses multicast address 224.0.0.5 (all OSPF routers) and 224.0.0.6 (all OSPF designated routers) or unicast to communicate with neighbors
• Default administrative distance is 110
• Uses bandwidth as metric for best path selection
• Default reference bandwidth is 100 mpbs
• Cost is calculated by ref-bw / interface-bw (example: 100mpbs / 10mbps = cost 10)
• Supports authentication using clear text, MD5 or SHA
• Supports route summarization only at Area or Autonomous System Boundaries.
• Supports equal cost load-sharing
• Does not support split-horizon, but ignores self-originated LSAs - which is kind of the same thing.
• Uses Shortest Path First (SPF) algorithm to process the contents of the Link-State Database (LSDB)

Things that has to match in Hello packets for OSPF neighbor adjacency relationships to form:

• Authentication (if used)
• Hello and Dead timers
• Network Mask
• OSPF Area ID
• OSPF Area Type
• Link MTU size
• No duplicate RIDs

OSPF is a link-state routing protocol, which means all routers have the entire network topology database and calculates the best paths to reach destinations using this topology. The benefits of this is that, unlike distance vector protocols, OSPF routers know exactly what the network looks like from the perspective of all its neighbors - the drawback, though, is the resource consumption of having to maintain a full overview of the topology on every single router. So, when it is said that all OSPF routers must know the exact same topology it is not the entire truth - the truth is that ALL routers in the same area must know the exact topology. 

Areas are a way of dividing an OSPF domain into logical groupings of routers. It allows for smaller topology databases and also enables the routers on the area borders to summarize networks advertised between the OSPF areas. These routers are known as Area Border Routers (ABR).

For OSPF to function properly in a multi-area design, all areas must be connected to area 0, which is the backbone area in OSPF. The reason for this is that ABRs only advertise non-backbone area networks into area 0.

Below is a drawing of a network with two different area configuration - the left one is improper area design and will cause routes in area 4 to be missing from on neighbor routers and the one on the right is a way to fix that design flaw by removing area 4 and including the network into area 3 instead, which will allow for all routes to be available throughout the OSPF multi-area domain.

OSPF Area Designs

The use of areas in OSPF also serves to reduce the flooding of Link-State Advertisements (LSAs) between routers. LSAs describes different network properties depending on the type of LSA. OSPF routers flood different types of LSAs based on its role in the network. In a non-backbone area it will be normal to have LSA types 1 and 2 and ABRs will send type 3 LSAs into the backbone area.

OSPF uses different network types for interfaces enabled for OSPF. The reason is to allow OSPF to determine its behaviour in regards to the following:

• Whether there will be an election of a DR/BDR on that interface
• Whether to use multicast or unicast to communicate with neighbors
• Whether two or more routers are allowed on the same subnet

Below is a table listing the different network types and the OSPF behaviour they dictate.

OSPF Network Types

A last note I want to put on OSPF is that it does not calculate based on the best way to reach a prefix - instad it finds the best way to reach the node (router) that advertises the prefix. The end result is pretty much the same, but if you think about it, one router can have many prefixes and so if you calculate based on each prefix you will have to calculate many times - whereas if you calculate the best path to the node you have the answer to ALL the prefixes with a single calculation.

EIGRP Overview

Back when I took my CCNA and subsequently my CCNP, I really liked working with EIGRP. I found it easier to configure and understand than OSPF, but still with a lot more stability and features than RIPv2. I haven't ever come across an installation where it was used in the real world, though, so my experience with EIGRP is only from the lab and a short period where I used it for my own routing protocol at home (with a DMVPN connection to a few other routers over the big web).

Cisco opened up the protocol to the public back in 2013 - but I haven't heard of any vendor supporting it yet. It was also not released in full - Cisco keeps all the fancy features locked up tight. I hope the protocol will gain some traction, but I do not think it is going to happen any time soon.

Quick sidenote: EIGRP got a "facelift" in IOS release 15.0(1)M and introduced a new cli structure for configuring EIGRP parameters. This new method was called "Named Mode" and the previous method of configuring EIGRP was retroactively renamed Classic Mode. The new Named Mode collects all the configuration elements of EIGRP under the process configuration - no more EIGRP interface sub-commands and stuff like that. I will have a separate post about the new Named Mode soon.

This is to be a (somewhat) quick overview of Cisco's routing protocol the Enhanced Interior Gateway Routing Protocol (EIGRP).

• Classless distance vector routing protocol (sometimes referred to as a hybrid routing protocol)
• Cisco proprietary
• IETF Draft draft-savage-eigrp-02
• Uses IP protocol 88
• Sends Hello messages
• Used to form neighbor adjacencies
• Used as a keepalive between neighbors
• Default Hello interval is 5 seconds
• Default on slow (1544kbps and slower) NBMA link is 60 seconds
• Hello messages are sent unreliably
• Uses a Holddown timer
• Default Holddown timer is set to 15 seconds
• Default on slow NBMA link is 180 seconds
• Sends partial and full updates
• Updates are triggered
• Uses reliable transport protocol (RTP)
• Uses multicast address 224.0.0.10 for IPv4 and FF02::A for IPv6
• Retransmissions are sent to each neighbor's unicast address
• Default administrative distance
• Internal: 90
• External: 170
• Uses a composite metric
• Defaults to using bandwidth and delay to determine the best path
• The composite metric can be weighted by tuning the K values 1 through 5
• The K values must match on all routers
• Supports a maximum hop count of 255 with the default set to 100
• The hop count is mainly used as a loop-prevention mechanism
• EIGRP defaults to using a maximum of 50% of the bandwidth on a link for exchanging hello and updates
• This can be tuned using the interface level sub-command ip bandwidth-percent eigrp <as#> <seconds>
• Supports authentication using MD5 (SHA is supported when using Named Mode)
• Supports route tags
• Supports next-hop advertisement
• Supports manual route summarization in any arbitrary point in the network
• Supports IPv4 and IPv6
• Supports unequal cost load-sharing
• Supports split-horizon with poison reverse
• Uses Diffusing Update Algorithm (DUAL) to control diffusing computations of the topology

Things that have to match for adjacencies to form in EIGRP:

• Authentication (if used)
• K values
• Autonomous System (AS) number
• Primary addresses on interfaces configured in the same common subnet

The last item warrants a little more explanation and I have made a post that goes into more detail regarding this point here. 

The EIGRP composite metric is calculated using these five K values:

1. Bandwidth
2. Load
3. Delay
4. Reliability
5. Maximum Transmission Unit (MTU)

By default, EIGRP uses only K values 1 and 3. This means that bandwidth and delay are the only values used in the composite metric. When manually tweaking EIGRP metrics it is recommended only to use the delay because the bandwidth is also used by other features such as QoS - whereas delay is only used by EIGRP.

EIGRP uses passive to show a route as stable and active to show a route that is in trouble - meaning a route that has been lost and it is now actively trying to find a new path to the network.

When a router loses reachability to a network it will send out queries to its adjacent neighbors to see if they have a path to the lost network. When this happens, the route is marked as active until replies are heard back from all the neighbors queried or the active timer runs out.
If a reply is not heard within 90 seconds, the local router will send an SIA-query (SIA meaning stuck-in-active) in an attempt to ascertain the reason for the missing reply - or more specifically, is the neighbor still working on the query request or did it not receive the initial query at all. Failure to respond to the SIA-query will result in the local router deleting routes through the non-responsive neighbor and resetting the adjacency. If the neighbor responds to the SIA-query, the active timer will be reset and another SIA-query will be sent again at half the active timer (90 seconds). This allows for an extension of the active timer if the reason behind the slowdown is the neighbors waiting for the active process to complete. A maximum of 3 SIA-queries will be sent before the neighbor adjacency will be reset.

EIGRP supports a graceful shutdown function, where the router sends a hello packet to its neighbor with all the K values set to 255. This happens when an interface running EIGRP is shutdown or the EIGRP process itself is shutdown. It enables the router to signal its neighbors to terminate the adjacency and allows the neighbors to initiate the process of finding an alternate route to the networks advertised by the router shutting down immediately instead of having to wait for the holddown timer to expire.

Below are a few nifty show commands for EIGRP.

The command show ip eigrp traffic gives a statistic of packets sent and received for the EIGRP proces.

The command show ip eigrp neighbors gives a view of the EIGRP adjacency table.

The command show ip route eigrp shows the EIGRP routes currently installed into the routing table.
The command show ip eigrp timers gives a view of the current hello and holddown timers for the EIGRP enabled interfaces.
The command show ip eigrp topology will show the EIGRP topology and will also display the EIGRP process router-id. With the keyword all-links it is possible to view the entire topology as advertised by neighbors (including feasible successor links).

RIPng Overview

So, the eggheads of the networking industry couldn't bear an IP protocol without RIP and so we get RIPng for our IPv6 networks. The "ng" stands for Next Generation, but it is sometimes referred to as RIPv6 or IPv6 RIP.

Below are listed some of the facts of RIPng. The below summary is based on the defaults of Cisco's implementation of RIPng and there are only few differences compared to RIPv2 for IPv4.

• Defined in RFC 2080
• Runs on port UDP/521 (not 520 to avoid clashing with IPv4 RIP configurations)
• Sends updates to multicast address FF02::9
• Metric is still based on hop count with 15 being the maximum and 16 being infinity (unreachable)
• Unlike RIPv2, the sending router does not increment the hop count in advertised routes before sending it out to its neighbors. Instead, it does the most logical thing and advertises what it has in its routing table. The receiving router is responsible for incrementing the entries before entering it into its own routing table
• Default administrative distance is 120
• It is driven mainly by timers
• Update timer: 30 sec.
• sends out the entire routing table every 30 sec. on RIP enabled interfaces (routes affected by the split horizon rule are excluded from the update)
• Triggered updates occur when a route change occurs and an update, including only the changed route, is sent out. Regular updates are unaffected by this and are still sent per the update timer interval
• Cisco uses a jitter variable to avoid update synchronization, just like in RIPv2, but I am unclear on the specific details - I can only assume they function the same way.
• Expiration timer: 180 sec.
• Similar to RIPv2 invalid timer. The expiration timer tracks the validity of a specific route. It resets to 0 whenever a route is received in an update and a route is considered invalid if the route is not received within 180 seconds.
• After the expiration timer expires the route is advertised with a metric of 16 (unreachable) until it is purged from the routing table
• Holddown timer: 0 sec.
• Cisco defaults to not using the holddown timer in RIPng
• Garbage collection timer: 120 sec.
• Unlike RIPv1 and v2, RIPng garbage collection timer starts counting after the specific routes expiration timer is exceeded
• The route is advertised with a metric of 16 (unreachable) for 120 seconds - after which the route is purged from the routing table
• An update message can contain as many entries as the MTU size allows (unlike RIPv1 and v2, which only allows for 25 entries per update message)
• Does not natively support authentication
• It uses IPv6 built-in authentication features (I will find the time to do a post on that on a later date)
• The ring is able to tag routes being redistributed into the routing process
• Unlike RIPv1 and v2, RIPng supports multiple instances running on the same router
• Cisco uses named instances, where instance names are locally significant and do not have to match between routers
• Use the global configuration command ipv6 router rip <instance name> to enter the general process configuration mode
• Use the interface sub-command ipv6 rip <instance name> enable to enable RIPng on a specific interface

Below is a packet capture of a RIPng update message (also known as a response) sent from the IPv6 link-local address of FE80::13:3 to the IPv6 multicast address of FF02::9.

RIPng response message, including two prefixes

RIPv2 Overview

RIPv2 is a simple routing protocol - at least when compared to other major routing protocols like OSPF and BGP. The pros for using RIPv2 in a network is the ease of configuration and maintenance of the routes and also the network traffic generated by the protocol is somewhat less than that of other routing protocols. Also, most vendor equipment supports RIPv2 and so is a fairly common protocol to come by in smaller routing environments. The cons, however, are the protocols slow convergence time and lack of scalability.

Below are listed some of the quick hard facts of RIPv2. The below summary is based on the defaults of Cisco's implementation of RIPv2 - timers and the likes can vary from vendor to vendor.

• Defined in RFC 2453
• Supports classless routing operation (unlike RIPv1 which is only classfull)
• Runs on port UDP/520
• Sends updates to multicast address 224.0.0.9
• can be changed to unicast with the neighbor <ip address> command under the routing process
• can be changed to broadcast with the ip rip v2-broadcast command under a given interface
• Metric is based on hop count with 15 being the maximum and 16 being infinity (unreachable)
• The sending router increments the hop count in advertised routes before sending it out to its neighbors. Thus, receiving routers do not increment the metric, but enters the metric directly into its routing table
• Default administrative distance is 120
• It is driven mainly by timers
• Update timer: 30 sec.
• sends out the entire routing table every 30 sec. on RIP enabled interfaces (routes affected by the split horizon rule are excluded from the update)
• Triggered updates occur when a route change occurs and an update, including only the changed route, is sent out. Regular updates are unaffected by this and are still sent per the update timer interval
• Cisco implements a RIP_JITTER variable that randomly subtracts 0-15% from the 30 second timer to avoid the synchronization of routing updates with its neighbors. This changes the effective update interval to between 25,5 and 30 seconds
• Invalid timer: 180 sec.
• The invalid timer tracks the validity of a specific route. It resets to 0 whenever a route is received in an update and a route is considered invalid after 180 sec.
• After the invalid timer expires the route is advertised with a metric of 16 (unreachable) until it is purged from the routing table
• Holddown timer: 180 sec.
• After the invalid timer expires the holddown timer starts counting. Even if a valid route is received in an update, it will not be entered into the routing table until the holddown timer expires or the route is flushed from the routing table (either manually or by the timer)
• Flush after timer: 240 sec.
• The flush after timer (or garbage collection timer) starts counting after the last routing update is received - effectively counting alongside the invalid timer and subsequently the holddown timer
• By default, 60 seconds after the invalid timer expires (and only 60 seconds into the holddown timer) the flush after timer runs out and the route is purged from the routing table
• No neighbor adjacency is formed and no hello packets are sent
• An update message can contain up to 25 entries
• Supports authentication using plain-text or MD5 hashing
• RIPv2 is able to tag routes being redistributed into the routing process

Below is a packet capture of RIPv2 update (also known as a response) sent from 10.0.0.1 to a multicast address of 224.0.0.9. Worth noting is that the packet is filled with 25 network entries all with a metric of 1 except for the first entry being advertised with a metric of 16 due to a simulated network failure (interface shutdown) on the source router 10.0.0.2. Not shown in the screen dump is the subsequent packet sent from the router 10.0.0.2 including two additional subnets.

RIPv2 response message, including 25 entries

If we look deeper into one of the entries we can see that the entry includes a subnet mask (which is not included in RIPv1) making it possible to advertise variable length subnet masks (VLSM) - making it a classless routing protocol. Also, note the next-hop being set to all 0's, which means that the next-hop address is assumed to be the same as the source of the update (10.0.0.2).

RIPv2 response message entry

A short explanation of split-horizon is warranted. Split-horizon simply states that a router should not advertise a route out of the same interface that it learned it from. This is to prevent routing loops from occurring, but it can in some cases cause issues with routes not being sent to valid neighbors on DMVPN interfaces for example.

Address Resolution Protocol

Address Resolution Protocol (ARP - defined in RFC 826) is today mainly used in multi-access IP networks to identify the layer 2 address (MAC address) associated with a specific layer 3 address (IP address).

ARP request and ARP reply

This is done by sending a layer 2 broadcast requesting the MAC address for a specific IP address. To the right is a part of a packet capture of a client (172.17.6.72) broadcasting a request and then the server (172.17.6.5) responding to that request.

The ARP protocol is, strictly speaking a layer 2 protocol, but it carries information to facilitate layer 3 functions. As a layer 2 broadcast it is not routable, but by means of a proxy it can function between clients on different subnets.

Proxy ARP
Proxy ARP can facilitate communication between clients in a scenario where you wish to segment a larger IPv4 scope, but wish to change the addresses of hosts on the subnet gradually.

For example: you have a subnet of 192.168.0.0 /21. This network allows for more than 2000 hosts on the same broadcast domain. Say you would like to segment this /21 subnet into smaller /24 subnets, but some of the hosts include printers that have statically configure IP addresses and subnet masks on the devices. You configure your subnets so that clients are located on the subnet 192.168.1.0 /24 and the printers are in the subnet 192.168.2.0 /24. The clients acquire their address from a DHCP server so they will get the new /24 subnet mask automatically, but the printers are all statically configured with a subnet mask of /21. This means that the clients trying to contact a printer knows that the printers are on another subnet and therefore sends the traffic to their default gateway, but the printers will think that the clients are on the same layer 2 segment as them and will attempt to look them up using an ARP request.
This is where proxy ARP comes into play. It is configured on the interface of the router connected to the printer network so that if it receives an ARP request on the printer interface, requesting a MAC address of a client, it will go ahead and reply to the ARP request with its own MAC address in the reply. The result: the client routes traffic as it was supposed to and the printer sends the traffic to the MAC address of the ARP proxy router, thinking it is the MAC address of the client machine.
Now, the administrator in charge of changing the IP address (or at least the subnet mask) on the printers can do so at his or her own pace.

I am not saying this is a recommended scenario - just that it is possible given the proper circumstances.

There are many other uses for Proxy ARP, which is turned on by default on Cisco devices. You can turn it off on a per interface basis with the command no ip proxy-arp.

Gratuitous ARP
The gratuitous ARP is a special form of ARP request that functions like a reply, but a reply that no one asked for - hence the gratuitous part. It is an ARP request and not an ARP reply mainly because it would be the type of ARP message most likely to be processed by the largest audience of endpoints. More can be read about the specific reasoning here.

The following is true about a Gratuitous ARP packet.

• The destination MAC address is the layer 2 broadcast (ff:ff:ff:ff:ff:ff)
• The source and destination IP address is that of the host sending the gratuitous ARP packet
• No reply is expected

Gratuitous ARP is used to inform hosts on a subnet that a MAC address has changed. This feature is used by HSRP and VRRP to notify the network (mainly the switches) of where to forward packets to their virtual IP address.

ARP Probes
A feature in IPv4 uses ARP probes as a means of Address Conflict Detection (defined in RFC 5227) by using ARP requests to check if an IP address is already in use in the particular broadcast domain.

Reverse ARP
Reverse ARP is where an ARP request is sent out on a subnet with the source and destination MAC address being that of the sender and the source and destination IP address being all zeros (0.0.0.0). This allows a Reverse ARP server to reply to this request with a reply to the MAC address of the sender with an IP address, which needs to be manually defined on the Reverse ARP server beforehand. Essentially making an entry stating which IP address is associated with which MAC address. This is a means of dealing out IP addresses to hosts without statically configuring them on the hosts themselves. This is rarely used today (I have never encountered a network using Reverse ARP for addressing purposes) because of the cumbersome act of manually configuring the database with IP to MAC mappings and the need for the Reverse ARP server to be reachable on the clients layer 2 subnet.