I was going to talk about Dynamic Arp Inspection, but thought I had better talk about DHCP snooping first, since it is required for DAI.
Having a rogue DHCP server on your network is obviously a problem, so we can block this at the switch level. DHCP snooping actually keeps a table of DHCP binding information for each port (that you leave untrusted). First you enable it globally with ip dhcp snooping. Then you enable it per vlan with the ip dhcp snooping vlan number (you can use a range of vlan numbers here as well).
Next you need to manually set all your trusted interfaces. This means all your switch uplinks, as well as any DHCP servers. These ports must be trusted to allow DHCP responses to traverse the interface inbound (from the server to the switch).
This means regular clients should always be on an untrusted port so that they cannot act as an DHCP server.
Other options include rate limiting. Ip dhcp snooping limit rate rate will allow you to limit how many requests a client on an untrusted port can make as well. Set this on a per-interface basis.
DHCP snooping binding tables include MAC address, IP address, lease time, binding type,VLAN number, and interface information
Friday, May 28, 2010
Host Unreachable Reply
You ever try to ping something and you get the reply "host unreachable" so you wonder, how am I getting a reply if it is unreachable?
Well the reply is actually from the router, and the host is, as it says, unreachable. The router can't forward the ping, so it sends you a friendly reply. You can turn this off with the command no ip unreachables, and the router will silently let your packet drop and your ping time-out.
On a similar note, one major DOS attack is to send a flood of packets to unreachable address(es), causing the router to reply to each of these requests with an ip unreachable. If you want to still have the unreachables, you can rate limit responses. For instance:
Router(config)# ip icmp rate-limit unreachable 1000
This will limit the router to one reply per second.
Well the reply is actually from the router, and the host is, as it says, unreachable. The router can't forward the ping, so it sends you a friendly reply. You can turn this off with the command no ip unreachables, and the router will silently let your packet drop and your ping time-out.
On a similar note, one major DOS attack is to send a flood of packets to unreachable address(es), causing the router to reply to each of these requests with an ip unreachable. If you want to still have the unreachables, you can rate limit responses. For instance:
Router(config)# ip icmp rate-limit unreachable 1000
This will limit the router to one reply per second.
Thursday, May 27, 2010
RIP with discontiguous subnets
RIP(v1) routing is classful. This means the subnet mask is not sent along with routing updates, but rather assumed simply by the class of the subnet. Eg. 10.5.45.0 255.255.255.0 is advertised as a class A network, or 10.0.0.0/8. 192.168.9.0 is advertised as a class C and is advertised as 192.168.9.0/24.
So what if, as described in the below diagram, There are two different subnets being advertised that are not contiguous. Router A and C both know about separate 172.168 networks. The middle router will see identical route advertisements from both sides.
How do you resolve this? Well, use RIPv2, EIGRP, OSPF, or IS-IS (and don't summarize either of the 172.168 routes). This situation is just one of the reasons why classful routing is not used much any more, but watch out for a question like this on a CCNA test.
So what if, as described in the below diagram, There are two different subnets being advertised that are not contiguous. Router A and C both know about separate 172.168 networks. The middle router will see identical route advertisements from both sides.
How do you resolve this? Well, use RIPv2, EIGRP, OSPF, or IS-IS (and don't summarize either of the 172.168 routes). This situation is just one of the reasons why classful routing is not used much any more, but watch out for a question like this on a CCNA test.
Wednesday, May 26, 2010
VTP
Someone asked me recently, "why would you not use VTP". Thought I could give a short blurb here.
VTP - VLAN Trunking Protocol
Cisco uses VTP (other vendors have MVRP (standards based) for the same thing) to share vlans among switches. If you had 30 switches in a building, that all needed to have a a vlan added, logging into 30 switches to add the vlan is certainly more work than doing it on a single switch.
First you decide what switches you think will need to all share the same vlans, and add them to the VTP domain. Set the VTP password, and set all but one or two of the switches to client mode (not necessary but helps keep things simpler if you always make changes to a single switch). You can then log into any of the server mode switches and add or remove a vlan, and the change will be propagated to the entire domain.
Transparent mode, a third option, allows you to add or remove vlans (like server mode) but will never send out it's own database to propagate the network.
Now back to the original question, why would you not want to use VTP.
1. You are a control freak and want to make sure you control every change individually.
2. The switches all need different vlans, they share very few. Having 20 different VTP domains with only 4 or 5 switches per domain would be more work keeping the domains straight than simply logging in and making the changes individually.
3. Too Many Vlans - 2950 switches and before, I believe (I know 3500s for sure), only support 64 vlans. If VTP propagates more than 64 vlans to those switches, random vlans are chosen to not be added. If a vlan that that switch needs is missing, you have problems.
4. If you are adding a switch to a production network, ALWAYS ALWAYS change to an unused domain and delete vlan.dat to erase the vlans. Verify that show vtp stat shows a 0 (or lower than your production network) revision number or you will lose all your vlans.
Common misconceptions:
1. Switches in Client mode can't overwrite the config on one in server mode
The vlan database used is decided entirely upon the revision number. Every time you add or remove a vlan, the revision number is increased by one and "should" be higher than all the other switches. Because it is higher it is passed out as the new database. If you bring in a switch in client mode with the same domain name and higher revision number, the entire database of all the other switches is lost forever, including those in server mode.
2. Only Client mode switches receive updates
Client mode only means that you cannot add or remove vlans directly to that switches command line. Apart from that, Server and Client modes are identical, they all receive updates.
3. Switches in Transparent mode do not pass any VTP updates
Transparent mode means the switch will not pass any copies of it's own database, if you connect two switches to the transparent with different revision numbers, the transparent switch will pass that info between them.
VTP - VLAN Trunking Protocol
Cisco uses VTP (other vendors have MVRP (standards based) for the same thing) to share vlans among switches. If you had 30 switches in a building, that all needed to have a a vlan added, logging into 30 switches to add the vlan is certainly more work than doing it on a single switch.
First you decide what switches you think will need to all share the same vlans, and add them to the VTP domain. Set the VTP password, and set all but one or two of the switches to client mode (not necessary but helps keep things simpler if you always make changes to a single switch). You can then log into any of the server mode switches and add or remove a vlan, and the change will be propagated to the entire domain.
Transparent mode, a third option, allows you to add or remove vlans (like server mode) but will never send out it's own database to propagate the network.
Now back to the original question, why would you not want to use VTP.
1. You are a control freak and want to make sure you control every change individually.
2. The switches all need different vlans, they share very few. Having 20 different VTP domains with only 4 or 5 switches per domain would be more work keeping the domains straight than simply logging in and making the changes individually.
3. Too Many Vlans - 2950 switches and before, I believe (I know 3500s for sure), only support 64 vlans. If VTP propagates more than 64 vlans to those switches, random vlans are chosen to not be added. If a vlan that that switch needs is missing, you have problems.
4. If you are adding a switch to a production network, ALWAYS ALWAYS change to an unused domain and delete vlan.dat to erase the vlans. Verify that show vtp stat shows a 0 (or lower than your production network) revision number or you will lose all your vlans.
Common misconceptions:
1. Switches in Client mode can't overwrite the config on one in server mode
The vlan database used is decided entirely upon the revision number. Every time you add or remove a vlan, the revision number is increased by one and "should" be higher than all the other switches. Because it is higher it is passed out as the new database. If you bring in a switch in client mode with the same domain name and higher revision number, the entire database of all the other switches is lost forever, including those in server mode.
2. Only Client mode switches receive updates
Client mode only means that you cannot add or remove vlans directly to that switches command line. Apart from that, Server and Client modes are identical, they all receive updates.
3. Switches in Transparent mode do not pass any VTP updates
Transparent mode means the switch will not pass any copies of it's own database, if you connect two switches to the transparent with different revision numbers, the transparent switch will pass that info between them.
Tuesday, May 25, 2010
Wireless Inter-Controller Roaming
Vocab -
lightweight access point - a "dumb" wireless device that basically just sends and receives traffic from the client and performs some simple encryption. Will not work without a controller to tell it what to do.
Controller - A device that controls lightweight access points, providing the SSIDs, authentication, routing, and security decisions.
Ok, so here is the problem. You have lightweight access points that talk to several different controllers. Now a client has a laptop or a phone, that has connected to your wireless network. They decide to walk around and the client moves out of range of one access point. The client's NIC drivers decide that the signal is too low and begin probing for a better signal, find one, and connect to a second AP. If the second AP is connected to the same controller, then there shouldn't be any problem. The roam from AP1 to AP2 is completed inside the controller with no data drop. Now say they continue walking to a different floor and need to move to AP3. AP3 is not only on a different controller, but a different subnet. Being on a different subnet means the client must request a new DHCP address, a long (say 15 second) process. During these 15 seconds the client's sessions are dropped, the phone call dies, the video stops streaming (your phone starts ringing).
Cisco's solution is a "mobility group". Under the Controller tab, you can expand "Mobility Management" and click mobility groups. This allows you to enter the Mac Address, IP, Mobility Group Name, and Multicast IP for the other controllers in your environment. By putting all (or all within a building or site) your controllers into a single mobility group, the controllers will constantly be talking over that multicast group to each other about what clients they have. When your client decides to move to a new controller, the original controller becomes an "anchor" controller.
Once the client has an anchor controller (C1) and has roamed to the new controller on a different subnet (C2) they send all their traffic through C2, who in turn passes everything to C1 for processing. This allows the client to retain their original IP address and avoid the connection drop that would have occured. C1 then passes the traffic out onto the wire (wired network), and all return traffic is sent to C1 and then passed to C2 and finally the client.
In older code versions, outbound traffic moved from client to C2, and was dropped out onto the wired network directly, and only return traffic proceded through both C1 and C2. The problem people found with this was when there was a firewall between the two controllers (eg. remote site) the outbound IP address was different than the return IP. I will save the firewall posts for another day, but simply put, a firewall will send a packet out, and automatically open a hole for the return packet. If that return packet is coming to a different IP, it doesn't fit in the waiting hole and gets dropped.
I know a drawing always helps me so I will try to provide them regularly. Here you can see the client before the roam on the left, sending traffic in and out of a single controller. After the roam, on the right, you can see traffic sent through both controllers in both directions.
lightweight access point - a "dumb" wireless device that basically just sends and receives traffic from the client and performs some simple encryption. Will not work without a controller to tell it what to do.
Controller - A device that controls lightweight access points, providing the SSIDs, authentication, routing, and security decisions.
Ok, so here is the problem. You have lightweight access points that talk to several different controllers. Now a client has a laptop or a phone, that has connected to your wireless network. They decide to walk around and the client moves out of range of one access point. The client's NIC drivers decide that the signal is too low and begin probing for a better signal, find one, and connect to a second AP. If the second AP is connected to the same controller, then there shouldn't be any problem. The roam from AP1 to AP2 is completed inside the controller with no data drop. Now say they continue walking to a different floor and need to move to AP3. AP3 is not only on a different controller, but a different subnet. Being on a different subnet means the client must request a new DHCP address, a long (say 15 second) process. During these 15 seconds the client's sessions are dropped, the phone call dies, the video stops streaming (your phone starts ringing).
Cisco's solution is a "mobility group". Under the Controller tab, you can expand "Mobility Management" and click mobility groups. This allows you to enter the Mac Address, IP, Mobility Group Name, and Multicast IP for the other controllers in your environment. By putting all (or all within a building or site) your controllers into a single mobility group, the controllers will constantly be talking over that multicast group to each other about what clients they have. When your client decides to move to a new controller, the original controller becomes an "anchor" controller.
Once the client has an anchor controller (C1) and has roamed to the new controller on a different subnet (C2) they send all their traffic through C2, who in turn passes everything to C1 for processing. This allows the client to retain their original IP address and avoid the connection drop that would have occured. C1 then passes the traffic out onto the wire (wired network), and all return traffic is sent to C1 and then passed to C2 and finally the client.
In older code versions, outbound traffic moved from client to C2, and was dropped out onto the wired network directly, and only return traffic proceded through both C1 and C2. The problem people found with this was when there was a firewall between the two controllers (eg. remote site) the outbound IP address was different than the return IP. I will save the firewall posts for another day, but simply put, a firewall will send a packet out, and automatically open a hole for the return packet. If that return packet is coming to a different IP, it doesn't fit in the waiting hole and gets dropped.
I know a drawing always helps me so I will try to provide them regularly. Here you can see the client before the roam on the left, sending traffic in and out of a single controller. After the roam, on the right, you can see traffic sent through both controllers in both directions.
First Post
I currently have a CCNA and CCNA+Security Certification and thought it would be helpful to myself and others to write blog posts about CCNA and CCNP subjects as I continue my studies.
Subscribe to:
Posts (Atom)
