Whispers & Screams
And Other Things

The EIGRP (Enhanced Interior Gateway Routing Protocol) metric

EIGRP (Enhanced Interior Gateway Routing Protocol) is a network protocol that lets routers exchange information more efficiently than was the case with older routing protocols. EIGRP which is a proprietary protocol evolved from IGRP (Interior Gateway Routing Protocol) and routers using either EIGRP and IGRP can interoperate because the metric (criteria used for selecting a route) used with one protocol can be translated into the metrics of the other protocol. It is this metric which we will examine in more detail.

Using EIGRP, a router keeps a copy of its neighbour’s routing tables. If it can’t find a route to a destination in one of these tables, it queries its neighbours for a route and they in turn query their neighbours until a route is found. When a routing table entry changes in one of the routers, it notifies its neighbours of the change. To keep all routers aware of the state of neighbours, each router sends out a periodic “hello” packet. A router from which no “hello” packet has been received in a certain period of time is assumed to be inoperative.

EIGRP uses the Diffusing-Update Algorithm (DUAL) to determine the most efficient (least cost) route to a destination. A DUAL finite state machine contains decision information used by the algorithm to determine the least-cost route (which considers distance and whether a destination path is loop-free).

Figure 1




The Diffusing Update Algorithm (DUAL) is a modification of the way distance-vector routing typically works that allows the router to identify loop free failover paths.  This concept is easier to grasp if you imagine it geographically. Consider the map of the UK midlands shown in Figure1. The numbers show approximate travel distance, in miles. Imagine that you live in Glasgow. From Glasgow, you need to determine the best path to Hull. Imagine that each of Glasgow’s neighbours advertises a path to Hull. Each neighbour advertises its cost (travel distance) to get to Hull. The cost from the neighbour to the destination is called the advertised distance. The cost from Glasgow itself is called the feasible distance.
In this example, Newcastle reports that if Glasgow routed to Hull through Newcastle, the total cost (feasible distance) is 302 miles, and that the remaining cost once the traffic gets to Newcastle is only 141 miles. Table1 shows distances reported from Glasgow to Hull going through each of Glasgow’s neighbours.

Table 1




Glasgow will select the route with the lowest feasible distance which is the path through Newcastle.

If the Glasgow-Newcastle road were to be closed, Glasgow knows it may fail over to Carlisle without creating a loop. Notice that the distance from Carlisle to Hull (211 miles) is less than the distance from Glasgow to Hull (302 miles). Because Carlisle is closer to Hull, routing through Hull does not involve driving to Carlisle and then driving back to Glasgow (as it would for Ayr). Carlisle is a guaranteed loop free path.

The idea that a path through a neighbour is loop free if the neighbour is closer is called the feasibility requirement and can be restated as "using a path where the neighbour's advertised distance is less than our feasible distance will not result in a loop."

The neighbour with the best path is referred to as the successor. Neighbours that meet the feasibility requirement are called feasible successors. In emergencies, EIGRP understands that using feasible successors will not cause a routing loop and instantly switches to the backup paths.

Notice that Ayr is not a feasible successor. Ayr's AD (337) is higher than Newcastle's FD (302). For all we know, driving to Hull through Ayr involves driving from Glasgow to Ayr, then turning around and driving back to Glasgow before continuing on to Hull (in fact, it does). Ayr will still be queried if the best path is lost and no feasible successors are available because potentially there could be a path that way; however, paths that do not
meet the feasibility requirement will not be inserted into the routing table without careful consideration.

EIGRP uses a sophisticated metric that considers bandwidth, load, reliability and delay. That metric is:




[latex]256, *, left(K_1, *, bandwidth ,+, dfrac {K_2 ,*, bandwidth}{256 - load}, +, K_3 ,*, delayright), *,dfrac {K_5}{reliability ,+, K_4}[/latex]


Although this equation looks intimidating, a little work will help you understand the maths and the impact the metric has on route selection.

You first need to understand that EIGRP selects path based on the fastest path. To do that it uses K-values to balance bandwidth and delay. The K-values are constants that are used to adjust the relative contribution of the various parameters to the total metric. In other words, if you wanted delay to be much more relatively important than bandwidth, you might set K3 to a much larger number.

You next need to understand the variables:

    • Bandwidth—Bandwidth is defined as (100 000 000 / slowest link in the path) kbps. Because routing protocols select the lowest metric, inverting the bandwidth (using it as the divisor) makes faster paths have lower costs.

 

    • Load and reliability—Load and reliability are 8-bit calculated values based on the performance of the link. Both are multiplied by a zero K-value, so neither is used.

 

    • Delay—Delay is a constant value on every interface type, and is stored in terms of microseconds. For example, serial links have a delay of 20,000 microseconds and Ethernet lines have a delay of 1000 microseconds. EIGRP uses the sum of all delays along the path, in tens of microseconds.



By default, K1=K3=1 and K2=K4=K5=0. Those who followed the maths will note that when K5=0 the metric is always zero. Because this is not useful, EIGRP simply ignores everything outside the parentheses. Therefore, given the default K-values the equation becomes:




[latex]256, *, left(1, *, bandwidth ,+, dfrac {0 ,*, bandwidth}{256 - load}, +, 1 ,*, delayright), *,dfrac {0}{reliability ,+, 0}[/latex]


Substituting the earlier description of variables, the equation becomes 100,000,000 divided by the chokepoint bandwidth plus the sum of the delays:




[latex]256, *, left(dfrac {10^7}{min(bandwidth)}, +,sum,dfrac {delays}{10}right)[/latex]


As a final note, it is important to remember that routers running EIGRP will not become neighbours unless they share K-values. That said however you really should not change the K-values from the default without a compelling reason.

Continue reading
472 Hits
0 Comments

Rapid Spanning Tree Protocol

The IEEE 802.1D Spanning Tree Protocol was designed to keep a switched or bridged network loop free, with adjustments made to the network topology dynamically. A topology change typically takes 30 seconds, with a port moving from the Blocking state to the Forwarding state after two intervals of the Forward Delay Timer. As technology has improved, 30 seconds has become an unbearable length of time to wait for a production network to fail over or "heal" itself during a problem.

The IEEE 802.1w standard was developed to used 802.1D's principal concepts and make the resulting convergence much faster. This is also known as the Rapid Spanning Tree Protocol (RSTP), which defines how switches must interact with each other to keep the network topology loop free, in a very efficient manner.

As with 802.1D, RSTP's basic functionality can be applied as a single instance or multiple instances. This can be done by using RSTP as the underlying mechanism for the Cisco-proprietary Per-VLAN Spanning Tree Protocol (PVST+). The resulting combination is called Rapid PVST+ (RPVST+). RSTP is also used as part of the IEEE 802.1s Multiple Spanning Tree (MST) operation. RSTP operates consistently in each, but replicating RSTP as multiple instances requires different approaches.

RSTP Port Behaviour
In 802.1D,each switch port is assigned a role and a state at any given time. Depending on the ports proximity to the Root Bridge, it takes on one of the following roles:

    • Root Port

 

    • Designated Port

 

    • Blocking Port (neither root nor designated)



Tge Cisco proprietary UplinkFast feature also reserved a hidden alternate port role for ports that offered parallel paths to the root but were in the Blocking state.

Each switch port is also assigned one of five possible states:

    • Disabled

 

    • Blocking

 

    • Listening

 

    • Learning

 

    • Forwarding



Only the forwarding state allows data to be sent and received. A ports state is somewhat tied to its role. For example, a blocking port cannot be a root port or a designated port.

RSTP achieves its rapid nature by letting each switch interact with its neighbours through each port. This interaction is performed based on a ports role, not strictly on the BPDU's that are relayed from the Root Bridge. After the role is determined, each port can be given a state that determines what it does with incoming data.

The Root Bridge in a network using RSTP is elected just as with 802.1D- by the lowest Bridge ID. After all switches agree on the identity of the root, the following port roles are determined.

    • Root Port - The one switch port on each switch that has the best root path cost to the root. This is identical to 802.1D. (By definition the root bridge has no root ports.)

 

    • Designated Port - The switch port on a network segment that has the best root path cost to the root.

 

    • Alternate Port - A port that has an alternative path to the root, different than the path the root port takes. This path is less desirable than that of the root port. (An example of this is an access-layer switch with two uplink ports; one becomes the root port, and the other is an alternate port.)

 

    • Backup port - A port that provides a redundant (but less desirable) connection to a segment where another switch port already connects. If that common segment is lost, the switch might or might not have a path back to the root.



RSTP defines port states only according to what the port does with incoming frames. (Naturally, if incoming frames are ignored or dropped, so are outgoing frames.) Any port role can have any of these port states:

    • Discarding - Incoming frames are simply dropped; no MAC addresses are learned. (This state combines the 802.1D Disabled, Blocking and Listening states because all three did not effectively forward anything. The Listening state is not needed because RSTP can quickly negotiate a state change without listening for BPDUs first.

 

    • Learning - Incoming frames are dropped but MAC addresses are learned.

 

    • Forwarding - Incoming frames are forwarded according to MAC addresses that have been (and are being) learned.

 

Continue reading
514 Hits
0 Comments

An examination of DHCP Snooping with option 82 on Cisco.

DHCP snooping is a DHCP feature that provides security by filtering untrusted DHCP messages from hosts or other devices on the network. DHCP snooping accomplishes this level of security by building and maintaining a DHCP snooping binding table.

An untrusted DHCP message is a DHCP message that the switch receives from outside the network or firewall or from an unauthorised DHCP server that can cause security attacks within a network. DHCP snooping is used along with the interface tracking feature, which inserts option 82 in the DHCP messages by the switch. Option 82 is the Relay Agent Information Option as described in RFC 3046.

The use of DHCP snooping extends existing security capabilities, including the capability to trust a port as a DHCP server and prevent unauthorised DHCP server responses from untrusted access ports. Another DHCP snooping supported feature is per-port DHCP message rate limiting, which is configurable in packets per second (pps) and is used to prevent DoS attacks. The DHCP snooping feature is useful in ISP networks, university campuses and Long Range Ethernet (LRE) network scenarios to prevent misconfigured or malicious DHCP servers from causing user-connectivity problems (such as giving out bogus DHCP addresses).

DHCP snooping builds a DHCP binding table that contains client IP addresses, MAC addresses, ports, VLAN numbers, leases and binding types. Switches support the enabling of the DHCP snooping feature on a per VLAN basis. With this feature the switch intercepts all DHCP messages within the layer 2 VLAN domain. With option 82 enabled, the Supervisor Engine adds the ingress module, port, VLAN and switch MAC address to the packet before forwarding the DHCP request to the DHCP server. The DHCP server can track the IP address that it assigns from the DHCP pool.

With this feature the switch restricts end-user ports (untrusted ports) to sending only DHCP requests, while all other types of DHCP traffic, such as DHCP offer responses, are dropped by the switch. DHCP snooping trusted ports are the ones connected to the known DHCP servers or uplink ports to the distribution switch that provide the path to the DHCP server. Trusted ports can send and receive any DHCP message . In this manner the switch allows only trusted DHCP serves to give out DHCP addresses via DHCP responses. Therefore this feature prevents users from setting up their own DHCP servers and providing unauthorised addresses.

In summary, DHCP snooping with option 82 provides an excellent mechanism to prevent DHCP DoS attacks or misconfigured clients from causing anomalous behaviour in the network.

Continue reading
516 Hits
0 Comments

Cisco finally given the go ahead to buy Starent Networks

starentLooks like Cisco's move into the world of radio/wireless is a go. The company announced yesterday that they have been given regulatory clearance and have now satisfied the regulatory approval requirements under the merger agreement to complete the acquisition of Starent Networks.

 

The have paid $2.9 billion, for Starent Networks, which makes products that help wireless telecommunications companies ship large volumes of data to phones and computing devices.

The deal represents about a 20 percent premium over Starent’s closing price on Monday 12th Oct  of $29.03 a share. After the announcement, Starent’s shares rose $4.88, or almost 17 percent, to close at $33.91 on the following day.

Starent counts carriers like Verizon Wireless, Sprint Nextel, Vodafone Group and China Telecom as customers.

The company’s recent deals reflect that optimism about the growing importance of video traffic to mobile networks. In October, Cisco began a tender offer to buy Tandberg, a Norwegian maker of videoconferencing systems, for $3 billion. And in March, Cisco agreed to pay $590 million for Pure Digital Technologies, a start-up that developed the popular Flip video cameras. The purchase of Pure Digital bolsters Cisco’s video and nascent consumer electronics efforts while also giving the company a way to promote devices that create bulky files that consume great deals of bandwidth.

While the Starent purchase has a video element, it is primarily a sign that Cisco expects smartphones and wireless data plans to rise in popularity. In addition, the acquisition offers another door through which Cisco can approach telecommunications companies that have turned to Ericsson, Alcatel-Lucent and Huawei Technologies for networking equipment that feeds mobile devices.

In a research report, Mark Sue, a networking analyst with RBC Capital Markets, valued the mobile carrier infrastructure market at $47.5 billion.

Starent, was founded in 2000 and has traded publicly since 2007. Last year, the company reported a 74 percent rise in revenue, to $254.1 million. Starent Networks is a leading provider of infrastructure solutions that enable mobile operators to deliver multimedia services to their subscribers. Their solutions combine significant computer power, memory, and traffic handling capabilities with highly distributed software architecture designed to provide high availability, flexibility, and performance built on the power of a Linux operating system. 

They have created solutions that provide several core network functions and services, including access from a wide range of radio networks to the operator's IP, or packet core network, mobility management of subscriber sessions, and call control. Their access-independent solution integrates multiple network functions needed for the delivery of advanced multimedia services, such as video, Internet access, voice-over-IP, e-mail, mobile TV, photo sharing, and gaming. 

They have developed multimedia core platforms and proprietary software specifically to address the needs of packet-based mobile networks. These products are designed to provide mobile operators with new revenue opportunities while also reducing their costs and they possess a high degree of system intelligence, which allows a mobile operator to understand the details of each subscriber session, enabling individual subscriber management and network traffic flow control.

Their products also enable mobile operators to continue to evolve their core networks to the Long Term Evolution (LTE) Evolved Packet Core (EPC) specification to provide multi-megabit bandwidth, latency reduction, and improved mobility to their subscribers.
Other product areas include CDMA, HSPA, WiMAX, WiFi and Femtocell which make for an interesting complement to Cisco's existing portfolio.
Continue reading
811 Hits
0 Comments