EIGRP Equal and UnEqual cost load balancing

By default, EIGRP load balances across up to 4 equal cost paths. EIGRP can also load balance over unequal cost paths as well.

1. How do I turn off EIGRP load balancing?

A. maximum-paths 1

2. How do I load balance over 16 paths

A. maximum-paths 16

3. I set up load balancing and am trace-routing the destination from my console, but it is only using one path

A. Load balancing is performed only on traffic passing through the router, not router generated traffic

4. I want to set up unequal cost load balancing, what do I do?

A. First you must determine the variance you wish to use. Take your FD (Feasible Distance) of your best route. Now what number do you need to multiply it by to include the FD of all other routes you wish to load balance across?

For instance, if your successor, or best route, has a FD of 10, and you want to load balance across paths with costs of 15 and 20, choose a variant of 2. Then, all FDs 20 or under will be included in unequal cost load balancing. If you wanted to load balance across a 25, choose a variance of 3 to include all FDs under 30. (*Note* to avoid loops, the FD of routes must also be less than the advertised distance of your successor route. Read my last post for more on this)

traffic-share balanced

variance [#]

5. The load balancing command also has a minimum command, when would I use that?

A. The traffic-share min across-interfaces command is used for OSPF and other protocols to turn on equal-cost load balancing. If you have changed to unequal cost load balancing you could use this to return to equal cost in EIGRP. This command will leave all of your variance chosen paths in the routing table (see #4) but packets will only be routed out the paths that are the least cost (minimum) route(s).

EIGRP Feasible Successor

EIGRP's DUAL (Diffusing Update Algorythm) uses a cost metric of links to choose routes. Without going into how those costs are calculated, we can talk about successors and feasible successors.

Advertised distance is the cost that is being passed or advertised by the neighbor router. In my diagram, I am looking at how R1 can get to the 192.168.0.0 network. There are three paths, and each advertise a cost. The top neighbor is advertising 3000, the middle 2500, and the bottom 4100. These paths are added to the EIGRP topology table.

Feasible distance (FD) is once R1 has taken those advertised distances and added the local link cost. FD is used to pick the best route to the destination. In our diagram the lowest FD is the top route at 4000 (AD + Local Link Cost or 3000 + 1000). This route would be pulled from the topology table and inserted in our routing table.

EIGRP can also have a Feasible Successor (FS). This is a loop free route used as a "backup" immediatly if the successor (main route) goes down. By doing this immediatly, the network does not need to reconverge to choose a new best path. To qualify as a FS, the next hop router must have an ADVERTISED DISTANCE of less than the current successor's Feasible Distance.

In our diagram, the top route has been chosen as successor, so now we look at the other two options for feasible successor. Even though the bottom route would have the lowest FD total, it does not qualify for a feasible successor because the advertised distance of 4100 is higher than the successor's FD of 4000. Looking now at the middle route, the advertised distance, 2500, is lower than the successor's feasible distance of 4000. The middle route qualifies and will be chosen as the Feasible Successor.

OSPF Authentication

OSPF can use MD5 or clear text authentication, as well as per area or per interface. Authentication is pretty simple so this should be a short post.

In my example, I will use Fa0/0 as the area facing interface, and secret as my key. I used OSPF process 150... because it was a nice number.

First we have a clear text example. We go into our fa0/0 interface, set the key and area. Then we go into our ospf process and tell all of area 0 to use "authentication" which just means clear text here. Do this on each router and you are set to go.

R1(config)#interface FastEthernet0/0
R1(config-if)#ip ospf authentication-key secret
R1(config-if)#ip ospf 150 area 0
R1(config-if)#
R1(config-if)#
R1(config-if)#router ospf 150
R1(config-router)#area 0 authentication

Now we have nearly the same config but using an md5 (message digest version 5) key. Go into the interface and this time use the message-digest-key, give the key a number, say md5, and enter secret as our key.

**A useful thing to note, notice this is key 1. If our security policy said we needed to change keys every 90 days, we could create key 2 on all our routers, wait a minute and the routers will detect that they all have a newer matching key and start using it, then we can eliminate key one without ever losing a connection. If we just changed key 1, no matter how fast we could type, the neighbor adjacency would have to be re-established meaning our routing would be down momentarily.

R1(config)#interface FastEthernet0/0
R1(config-if)#ip ospf message-digest-key 1 md5 secret
R1(config-if)#ip ospf 150 area 0
R1(config-if)#
R1(config-if)#
R1(config-if)#router ospf 150
R1(config-router)#area 0 authentication message-digest

Finally, instead of setting authentication up for the whole area, we can set it individually on interfaces. Perhaps you only have two routers with an interface each that you want to authenticate because you have a switch between them that a malicious/misconfigured router could plug into and join your OSPF domain. We simply go into the interface and turn on authentication, choose a password, and join the area.

R1(config)#interface FastEthernet0/0
R1(config-if)#ip ospf authentication message-digest
R1(config-if)#ip ospf message-digest-key 1 md5 secret
R1(config-if)#ip ospf 150 area 0

Crossover T1 vs Cat5

As I am getting together a CCNP lab, I came to find there is a difference between a T1 crossover and a Cat5 crossover. A T1 crossover switches pins 1,2,4,5 while Cat5 switches 1,2,3,6. For those of you used to making Cat5 crossovers, instead of swapping the "straddling" pair, swap the "straddled" pair.

I'll have to make myself a new cable or 2.

Network world has recently blogged about the best Routers and Switches for CCNP labs if anyone else is building a home lab.

Best Router for CCNP Prep in 2010 and Best Switch for CCNP Prep in 2010 and finally the full lab setup What to Buy?


Cat5 Cross over Cable

End 1
Pin – Description
1 – Green White
2 – Green
3 – Orange White
4 – Blue
5 – Blue White
6 – Orange
7 – White Brown
8 – Brown
End 2
Pin – Description
1 – Orange White
2 – Orange
3 – Green White
4 – Blue
5 – Blue White
6 – Green
7 – Brown White
8 – Brown


T1 Cross over Cable

End 1
Pin – Description
1 – Green White
2 – Green
3 – Orange White
4 – Blue
5 – Blue White
6 – Orange
7 – White Brown
8 – Brown
End 2
Pin – Description
1 – Blue
2 – Blue White
3 – Orange White
4 – Green White
5 – Green
6 – Orange
7 – Brown White
8 – Brown

*Note that this also means you lose your solid-stripe-solid-stripe pattern on one end.

OSPF area types Stub, Totally Stubby, Not so Stubby

I am starting with the pre-req that everyone understands basic OSPF, Areas, Area Border Routers (ABR), Autonomous Systems, and Autonomous System Border Routers (ASBR)

Alright, I know I'm jumping around a lot here, but things come up in real life, in forums, in books, and in all the blogs I follow that gets me headed off on another track, so today I am talking about OSPF stub area types.

First, what are the types of OSPF Link State Advertisements? These are how OSPF routers communicate routes and route changes etc.

Type1 - Router - router announcing itself and lists links to other routers with metrics in the same area
Type2 - Network - lists what routers are connected by the broadcast segment.
Type3 - Net Summary - An Area Border Router summarizes one area, and sends it to other areas
Type4 - ASBR Summary - An ASBR summarizes external routes that are injected from another routing protocol
Type5 - AS External - Full network routes imported from other routing protocols
Type6 - Group Membership - A multicast advertisement that is not used in OSPFv3
Type7 - NSSA External - Routers in a not so stubby area (NSSA) send external routing information to the ABR to be redistributed (as type 5s to other areas)

There are 11 types, but these are the ones that affect stub areas for this discussion.

First, why use stub areas? Stub areas greatly minimize the traffic and routing table sizes of routers in these stub areas, increasing performance. (And area 0 can't be a stub of any sort)

First we start out with a stub area. A stub area allows Type 2 and Type 3 LSAs. Type 5 LSAs are not passed into the area. A default route is also passed in from the ABR.
Now, what does that mean, Type 2 and Type 3 LSAs allow the area routers to get inter and intra area routes. Routes in the same area are seen as usual, and the routes on the other side of your ABR is visible. Routes that are injected from other protocols, like static or EIGRP, are not advertised. To get to these, the router must use the default route.
**Remember - Stub= No type 5 LSAs and default route

Next we'll look at a Totally Stubby network. Only Type 2 LSAs and a default route are passed into the area (although technically the default route is a type 3... but thats the only one).

This means the routes inside the area are advertised, but all other destinations will use the default route. In other words, to a router in a Totally Stubby area, the ABR is the end of the world and everything not in it's own little area gets passed to the ABR to deal with.
**Remember - Totally Stubby - ONLY Type 2 LSAs and default route

Next we have Not-So-Stubby Areas. NSSAs have Type 2, Type 3, and Type 7 LSAs.
Type 7 LSAs are ONLY found in NSSAs. A NSSA is when you want your area to have external routes and be able to pass them to other areas, but not have other area's external routes imported into this area. In other words, local external routes are allowed, but not external routes from other areas. The ABR changes the Type 7 into a Type 5 when it passes it to other areas.

Cisco says: "NSSAs are more flexible than stub areas in that an NSSA can import external routes into the OSPF routing domain, thereby providing transit service to small routing domains that are not part of the OSPF routing domain."
**Remember - NSSA - Type 2, 3, and 7 LSAs with default route

Finally, we get to Totally Not-So-Stubby Area or officially called Not-So-Stubby Totally Stubby Area (seriously). This combines the attributes of a Totally Stubby and a NSSA area. First you have the Totally Stubby in which Type 3 and 4 advertisements are not passed into the area (Everything outside of the area is found through a default gateway), but you can still connect an external route to the area by Type 7 LSA.
Why use this? Perhaps you have a remote site that you want to connect back by default route only, but it also has a backup DSL or Cable modem for local internet.
**Remember - Totally NSSA - Only Type 2 and 7 LSAs and default route.

STP- Difference between Link Cost and Port Priority

So, when would you want to change link cost and when would you want to change port priority in your spanning tree layout? Is there a difference?

VOCAB:
STP: Spanning Tree Protocol - Layer 2 loop avoidance protocol
BPDU - Briding Protocol Data Unit: Used by Spanning tree to communicate and determine the tree structure.

Spanning tree is a layer 2 protocol that prevents loops from forming. By sending BPDUs out all switch ports, a layer 2 device communicates with it's neighbors and a "tree" structure is developed. One device is determined as the root and all other switches pick a single lowest cost port, deemed the root port, to connect toward that root switch. All other ports that connect to the root can then be put into a blocking state. By doing this, a loop should never be able to develop.

To create the tree that fits your environment best, you can change all the settings. First set the switch priority to make sure the switch you want will be the root, then you can manipulate the path costs to determine the desired tree structure.

After the root switch is chosen, BPDUs are sent out from the root switch, starting with a cost of 0. As each switch recieves the BPDU, it adds the cost of the link the BPDU just traversed and floods it out the other ports. If a switch receives two or more BPDUs, the following is checked:

Lowest Root Bridge ID - part of choosing the root switch
Lowest Root Path Cost - The link "cost" to send traffic to the root switch as modified by all switches in the path
Lowest Sender Bridge ID - Used as a tie-breaker in the case of identical path costs
Lowest Sender Port ID - Used if all above methods are a tie

The lowest cost option is chosen as a root port. Ports connecting to another switch's root port are designated ports. All other ports leading back to the root can then be blocked.

I know that is a very quick overview of STP but I just wanted to focus on link cost vs port priority. I will likely delve further into other parts of STP at a later time.

So, why not just change path costs or just change bridge or port IDs to manage what your spanning tree looks like and what port is used as the root port. The answer lies in looking at the downstream switches rather than the switch you are configuring. If you have two equal cost connections to the root, you can change the cost of one to be higher or lower, manipulating the tree to your design. But you need to remember that path costs are added to the root path cost in each BPDU, bridge and port priorities are not. This means if you change the path cost to a notably lower cost, the switches further out on the branches will be offered a lower root path cost. If you instead choose your root port by changing the port priority or bridge priority, none of that information is carried along to the later switches.

Changing port/switch priorities can be a much administratively cleaner setup. If you have 50 100MB links, it would make sense for them all to have a cost of 19, or a network wide cost of your choosing rather than a mismatch of costs on each individual switch. That could make determining your path costs much more of a task.

Changing path costs can be useful in situations such as edge switches with uplinkfast. In order to ensure the switch is always chosen as a "leaf" node and is never traversed in a regular STP topology, the port costs are all increased by 3000. This is passed on to any switches further downstream making this switch very undesirable as part of the root path. This wouldn't work if the priorities were the only things increased as they are not passed on to other switches.

EIGRP BASICS - Split Horizon/Route Poisoning

Split horizon, in EIGRP, affects the sending of update and query type packets.

Update packets contain route change information (sent reliably, needs ACK).

Query packets are sent when a router does not have a feasible successor which is a next hop router for a backup path (sent reliably, needs ACK).

Split Horizon is a way to prevent (minimize) routing loops. The logic is that if a router uses interface A to get to a destination, there is no reason to advertise that route out intA.

For example, if network 10.1.1.0/24's next hop router is located out fa0/0, then the router will not send update packets containing 10.1.1.0/24 out of fa0/0, only out fa0/1, fa0/2, etc.

If you think about it, if router A is your next hop to a network, why would you need to tell router A how to get to itself?

Split horizon is on by default on all interfaces.

If a router changes the interface it uses to get to a destination, it momentarily turns off split horizon and commits route poisoning. Route poisoning is when the router, in order to stop other routers from using its old route/cost that it just changed, floods out route unreachable packets. This causes other routers to flush that old route out of their routing tables so that the new route can now be successfully added.

EIGRP Basics - Hello Packets

Vocab:
IGRP: Interior Gateway Routing Protocol
EIGRP: Enhanced Interior Gateway Routing Protocol
AS: Autonomous System - a group of routers share an AS so they know they are part of a routing group or system and should share routes and form relationships within that group. A router can be a member of multiple AS's but must inject routes between them if the two groups wish to share common routes.

Cisco loves to ask questions on it's own proprietary protocols, so don't skip over something just because it isn't the most common protocol out there. (although it looks like IGRP is getting phased out)

EIGRP Hello Packets:

EIGRP sends hello packets to the multicast address 224.0.0.10 in order to create and maintain Neighbor relationships. These are not "reliable" packets and so do not expect an acknowledgement. When a router receives an EIGRP hello packet, it first checks three items. Assuming it is configured with:

1. The same AS
2. The Primary IP address is in the same subnet
3. The metric-calculation constants match (how it determines route cost/metrics)

Then a neighbor adjacency relationship will be established.

Over a fast link (greater than T1) Hello packets are sent every 5 seconds (default). Over a slow link (T1 or slower) Hello packets are sent every 60 seconds (default).

Hello packets include the hold time. This is the time a router waits, and if it doesn't receive any EIGRP packets from the neighbor switch, flushes the routes and attempts to re-converge deciding the neighbor is down. Hold time, by default is 3 times the hello interval. This means fast links have a hold time of 15 seconds, while slow links are 180 seconds. Remember that changing the hello time does NOT automatically change the hold time, you need to remember to change both.

Issue the command show ip eigrp neighbors to see if your hello packets have formed an adjacency.

Floating Static Routes

Floating routes, are we levitating our routers now?

Say you have a primary route, using a routing protocol such as OSPF and you want to input a manual static backup route. Well, the administrative distance of a static route is always 1, so your backup route would always be chosen over the primary OSPF route which has an administrative distance of 110.

Floating static routes are when you manually set the administrative distance of a static route to be higher than your routing protocol. This way the route "floats" above the primary route until that route goes down, only then will the static route be entered into your routing table. Simple concept with a fancy name.

Enter your static route with the command:

ip route [destination net] [subnet] [next hop] [Admin Distance]
ip route 172.16.1.0 255.255.255.0 192.168.1.1 112

Notice the administrative distance I chose was 112, higher than OSPF's 110, so that the OSPF route will be used while it is active. You can choose any admin distance up to 255.

Port Based Authentication (Dot1x auth)

Most of my study time the last few days has been devoted to Port Authentication using dot1x (802.1x). Going to my BCMSN book was honestly not a lot of help since it appears the CCNP only requires you to know how to set up the simplest authentication, only for wired, and only the switch commands. I will cover, perhaps a bit more than the switching exam expects you to know, but it is an involved process so it will still be an overview.

Why do you need port authentication? Well suppose someone brings in a laptop from home full of virus', or a malicious user decides to unplug a work computer and use the network cable to plug in their own laptop to attack your network. (I know everyone has perfect, aware, tech savy, completely trusted employees and users, but this is just theoretical)

Cisco QOS trust boundaries

Vocab:

QOS - Quality of Service - Prioritizing packets so that time or delay sensitive applications move through the network first.
COS - Class of Service - Layer 2 QOS, also referred to as IP Precedence, what a switch uses to determin priorities (0-7)
DSCP - differentiated services code point - Layer 3 QOS, what routers use to determine qos priority. Six bits give you 63 levels, but I believe only 56 are usually used.
-Devices keep a map to translate COS and DSCP values, switching between the two as needed, but every device can have a different map, so a COS value of 5 is not always translated to DSCP 46.


Ok, since I got qos trust questions both times I took the BCMSN, I thought I had better cover it. You should be able to look at a diagram and write/match a config or vice versa.

Since VoIP phones have a jack for a PC in the back, the question of trusting QOS values comes into play. The options are to re-write all the QOS values on the switch, therby not trusting the phone or the PC. You can trust the phone's default QOS tag, or tell it what QOS tag to use, therby trusting the phone to act correctly. Last, if you have a PC plugged in the back of the phone that needs special QOS for an application, you can instruct the phone to pass on the PC's QOS tags without changing them, and trust everything.

Case one is to simply re-write all QOS values at the switch port. You can do this by choosing a cos value followed by the command instructing the switch to override all qos tags with the value you just chose.

mls qos cos [#]
mls qos cos override

Case two is the default. You can simply let the switch do it's thing, and it will trust the qos values of the phone, while the phone rewrites any qos values the PC may attempt to use. The other option that results in the same trust boundary is to instruct the phone to use a particular COS value. Even though the switch is instructing the phone to use a particular COS value, you are still trusting the phone to listen and act as instructed, hence the trust boundary after the phone.

mls qos trust cos
switchport priority extend cos [#]

Case three is not as common. This instructs the phone to not re-write any qos values on the packets coming in from the PC, and to pass them on as is so that the switch uses those qos values. Only extend the trust to the PC if the computer is under your control/management and has a specific need for an application to have qos priority, such as a soft phone.

switchport priority extend trust

Voice Vlans

Cisco phones (and most enterprise VoIP phones), have a jack in the back to hook a computer to. This means inside the phone is a embedded 3 port switch. One port is to the pc, one to the voice stream or the phone itself, and one is the uplink from your company switch. If you use port security, this means you should allow 3 mac addresses on the port. The phone's mac address can be learned on both the voice and data vlans, and the computer's will be learned on the data. (although I have only ever seen two, this is cisco best practice)


Note that cisco phones expect CDP to be enabled on the switch ports as they use it for both choosing the correct PoE levels and to negotiate a special dot1Q(802.1Q) trunk.

So there are 4 modes to set up a switch port you expect to plug a phone into.

The Voice Vlan command is: switchport voice vlan [vlan-id | dot1p | untagged | none]

1. First you can just use a regular access port. (in voice vlans, it is referred to as none) In this mode, both the phone traffic and pc data both land on the same access vlan and there is no way to distinguish between the two. Two things to note, because the traffic is inter-mingled you have a security risk as well as having no ability to provide QOS (quality of service) priority to only the phone. Any QOS is applied to all traffic coming in that switch port. Specify switchport mode access to use this, or use default switchport voice vlan none command

2. Now we see the special 802.1Q trunk where CDP is required. The second mode is referred to as "untagged". Now cisco doesn't use the term untagged nearly as much as other network vendors, but when you create a dot1Q trunk, every packet entering the switch needs to have a vlan tag to specify what vlan number it belongs to. Any packets entering the trunk port without a vlan tag, is dumped into the untagged vlan, or as cisco calls it a native vlan. By default this is vlan 1, so you probably need to specify a untagged vlan for this method. Specify the native or untagged vlan with the interface command switchport trunk native vlan [vlan #]. Then you use the voice vlan command to instruct the phone to send it's voice packets without attaching a vlan tag. switchport voice vlan untagged

3. Third we have the dot1p mode. In this mode, you gain the qos abilities. The phone will actually tag it's own voice traffic with vlan 0, and send it with a 802.1p priority of 5 by default. (call control gets a priority of 3). The benefit of this mode is that you get QOS abilities without needing a separate voice vlan created on your switches and routers. switchport voice vlan dot1p

4. Fourth is the most common (and best in my opinion) the vlan-id option. Create a vlan on your routers and switches that will be used just for phones. The phone will now send voice packets tagged with your voice vlan ID to the switch, with qos priority, while the data packets are sent along untagged to the access vlan. The command is switchport voice vlan [vlanID]

Methods 2, 3, and 4 use a special dot1Q trunk that is negotiated through cdp messages and carries only up to 2 vlans for voice and pc traffic.

To set a different qos priority to the phone for it's voice packets, use the interface command switchport priority extend [cos value] (you can also extend trust to the pc with the same command, but since I know you will get QOS trust boundary questions on the BCMSN test, I will give it it's own post.)

To display voice vlan configurations for an interface, type show interface [interface id] or simply show running interface [interface id]

*CDP should always be enabled on an interface with a cisco phone plugged in for voice vlan, trust, power settings, and qos to be set up properly with the phone.

*voice vlans automatically enable spanning-tree portfast (and does not disable when your remove the voice vlan)

*voice vlans can cause conflicts with private vlans, do not enable them on the same port

TCP Sequence Numbers

Jeremy Stretch in his PacketLife.net blog has great instructions for using wireshark to look at TCP sequence numbers in a simple packet capture. It includes a wireshark capture for you to follow along with. Take a look!

ACLs to mitigate spoofed IP addresses

ACL (COMMON) ENTREE FORMULA:
Permit/Deny [protocol] [sourceIP] [InvertedSourceMask] [DestinationIP] [InvertedDestMask] eq [optionalPort#]

---

Ok, here is a subject that I have been going back and forth on in a forum. First we will use some logic. You have private IP addresses that are non routable on the internet (10.0.0.0 192.168.0.0 172.16.0.0 127.0.0.0 etc.), so we conclude that these addresses should never being entering the outside of your firewall.

Just looking at that angle, we can then put some deny statements on our OUTSIDE inbound interface (traffic from the internet) to deny them before we permit traffic to our web servers.

deny ip 10.0.0.0 0.255.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
permit tcp any [webserverIP] eq 80

Remembering that ACLs are read sequentially from the top, we have just denied anyone who tried to spoof their source IP as a private address from accessing our web server, and allowed everyone else on the internet in on port 80. We can rely on the implicit deny at the end to block all traffic to any other ports on our webserver.

Now what if there is a user inside your network trying to spoof IP addresses. I would suggest having ACLs on each of your routers. If building A has a subnet of 172.16.45.0/24, then you can apply an ACL such as the following to make sure ONLY addresses from inside that subnet are allowed out. (You need to allow it to any, unless you want to specify every website your users are allowed to visit... unlikely.)

permit ip 172.16.45.0 0.0.0.255 any

Unless of course you have a proxy server, then you can really tighten your ACL with:

permit tcp 172.16.45.0 0.0.0.255 [webProxyIP] 0.0.0.0 eq 8080

this allows ONLY your subnet (no other spoofed IPs) to access ONLY your proxy server ONLY on port 8080.


Basically, you just need to draw out your network, and write ACLs to make sure only those addresses that you have provided (DHCP or STATIC) are allowed to be used as source addresses. Also remember that private IP addresses should NEVER be entering your network from your ISP.

LISP

I don't believe it is part of the CCNP yet, but cisco is pushing LISP and it could show up in the future. LISP (Locator ID Separation Protocol) is an open standard created by cisco. It attempts to reduce complexity and simplify Routing over the internet.

LISP separates the routing locator from the endpoint identifier into two numbering spaces. Primarily, this means routers will have far smaller routing tables if the routing table only has to hold the route portion of addresses. The host portion of the address is encapsulated inside the route headed packet. This is also intended to make multi-homing far easier, aimed at medium to small sized businesses. Multi-homing is "load leveling" between separate ISPs.

LISP works between LISP and non LISP networks, LISP IPv4 to IPv6, and two LISP IPv6 sites can communicate overtop of an IPv4 ISP network between them (or IPv4 to IPv4 over a fully IPv6 network).

More information at lisp4.cisco.com
Facebook is one of the big beta testers at www.lisp4.facebook.com

Format Change

I played around with the colors and format to make the bold commands pop out more. Also stretches width with browser so my graphics aren't permanently shortened. Anyone have thoughts feel free to comment. I can go back to black and gray or some other color scheme without much problem.

DAI (Dynamic Arp Inspection)

First, if anyone doesn't know about DHCP snooping, you may want to read the previous post about it, although all you need to know in regard to DAI is that you need to turn DHCP snooping on, and it will collect a database of IP/MAC/Interface/Leasetime/etc. of all DHCP requests it sees. You can also statically add addresses for static IP'd devices.

Next, I'll quickly explain ARP and CAM tables. Every switch stores a copy of what mac address(es) are located off each interface in a CAM table (content addressable memory). If the host hasn't sent or received a packet in a while (or is unplugged), the mac address will time-out and be removed from the cam table. To find that mac address next time a packet comes, the switch must broadcast (flood) out packets to all switch ports and wait for a response.

ARP is the address resolution protocol. Routers keep an ARP table, or a list of what IP addresses match what mac addresses. (view with the command: show IP arp) The router is then able to rewrite the destination mac address on incoming packets to the matching IP/MAC entree so that the layer 2 edge switches can find the host (since layer 2 switches ONLY understand mac addresses, know your OSI model).

For example: The diagram describes a regular ARP request. The router must flood out an ARP request to find the destination host's mac address, re-write the packet header and then is able to send the packet. (This ARP request/cam table fill, is why the first ping of a host that hasn't sent packets lately or is new to the network will always fail. The second or third will work correctly.)

Now, what if people didn't play so nicely. What if a malicious host on port 2 of the layer 2 switch responded to the ARP request before the real client saying THEY had mac address bbbb.1111.bbbb and IP address 192.168.5.3. The router would update it's ARP table to match 192.168.5.3 with mac bbbb.1111.bbbb, and the switch would include the mac in it's cam table for port 2. Any new packets sent to 192.168.5.3 would be sent to the malicious host, who can then forward it to the real host after assessing it's contents if it wishes. This attack is known as ARP spoofing or ARP poisening.

Enter Dynamic ARP inspection. DAI works similar to DHCP snooping, in that all ports need to be set as either trusted or untrusted. All packets entering an untrusted port are intercepted and checked, while trusted ports (switch uplinks) pass traffic without DAI checking anything. If a packet enters an untrusted port but doesn't match the information gathered either statically or in the DHCP snooping database, the packet is dropped and a log message created.

Commands: (Assuming you already have DHCP snooping running) turn on DAI on client vlans.

Switch(config)#ip arp inspection vlan vlan range

All switch ports in those vlans are now considered un-trusted. Make any switch uplinks or explicitly trusted ports trusted with the interface command

switch(config-if)#ip arp inspection trust

For static IPs that are not included in the DHCP snooping database, you can use an access-list. (Note that this is not a regular ACL as it includes a mac address and only the sender information. This is specifically an arp ACL)

arp access-list aclName
permit ip host senderIP mac host sender Mac Address [log]
(repeat this as needed for more static entrees)
exit
ip arp inspection filter aclName vlan Vlan range


One further thing you can do. By default this only checks the ARP reply's message body, you can also verify the ARP reply's packet header for further security.

ip arp inspection validate {[src-mac] [dst-mac] [ip]}

IP Source Guard

Ok, so last time we talked about how DHCP snooping can mitigate a man-in-the-middle attack. This was when a rogue DHCP server sends out it's own DHCP replies with itself as the default gateway, snoops the packet, then sends it on to the true default gateway so users would never know anything was wrong. DHCP snooping blocks those untrusted DHCP replies and creates a binding table of all the client IP addresses. We can now look at IP Source Guard.

In general, IP addresses are assigned and used "on the honor system" with nothing in place to make sure clients are only using their own. Common uses are to disguise denial of service attacks. If a lot of requests could come from an IP address, but their is no return address to send the replies to, or to track down the offending computer.

Between vlans this might be simple to detect, if the 192.168.5.0 network is in vlan 5, then that network appearing out of any other vlan can be dropped. What about when the spoofed IP address is inside the proper vlan, the user is just using a random or stolen IP from inside it's own subnet?

IP source guard comes into play. Using the DHCP snooping database or statically entered bindings, all packets entering the switch verify that the port, IP address, and mac address all match the database or the packet is dropped.

Turn this feature on by entering each interface and adding:
Switch(config-if)#ip verify source [port-security]
(Port security can be added to verify the mac addresses).

show ip verify source will show you the status of your IP source guard configurations.