September 3, 2010

IP Multicast for the Intimidated: A Primer

July 30, 2010 3 Comments
x
Bookmark

ip multicastLet me ask you this: What is it about IP multicast that gives most people panic attacks?

For me, IP Multicast was scary and different than what I was used to; it is a little counterintuitive when you are used to dealing with standard IP unicast and broadcast concepts. Plus, there are a lot of new terms and concepts that come with IP multicast, and that can be overwhelming.

I’m fortunate: I happen to work in an environment where IP multicast is an integral part of a software suite that was developed in-house. The fact that IP multicast is so important to a product we support really forced me to have to learn and understand IP multicast, and specifically on Cisco infrastructure.

Since this article is designed to be a gentle introduction, I will concentrate on defining some crucial IP multicast terminology and some very general concepts of multicast.

Definition: IP Multicast

The Cisco IP Multicast Glossary has this definition of IP multicast:

  • A routing technique that allows IP traffic to be sent from one source or multiple sources and delivered to multiple destinations. Instead of sending multiple packets to each destination, a single packet is sent to a group of destinations, known as a multicast group, which is defined by a single IP destination group address.

In multicast, our source hosts, also called senders, send out a group of packets (sometimes called a stream) to a multicast group IP address. Multicast IP addresses are Class D addresses (224.0.0.0/4); there are many IPs in this range that are reserved for administrative (routing, etc) functions, but there are also IPs set aside that are like RFC 1918 addresses in the unicast world, meaning you can use them on your internal network  and not on the Internet. Different hosts on a network within your administrative control (your LAN) can subscribe to the group IP to receive the content that is being sent from the source host.  Unlike IP broadcast, which is ‘one-to-all’ whether a host wishes to receive traffic or not, IP multicast protocols allow hosts to selectively receive the traffic they want, and hosts that don’t want that traffic don’t get it.

Definition: IGMP

IGMP, the Internet Group Management Protocol (originally specified in RFC 1112), is a standards-based protocol that provides a protocol for hosts on a LAN to tell their local router that they want to receive certain IP multicast group traffic. The point of IGMP was and is to allow hosts to dynamically register to receive the desired multicast traffic.

There are three versions of IGMP, appropriately named version 1, 2 and 3. Each version has characteristics that I will attempt to cover in future articles. The key point to remember here is that IGMP is how a host on your LAN tells its router that it wants to receive a certain multicast group.

Definition: PIM

Protocol Independent Multicast, PIM, is the multicast routing protocol that allows existing IP networks to route IP multicast, regardless of what unicast routing protocol is in use. You could be using EIGRP, OSPF, ISIS, even iBGP; PIM was designed to work over any existing IP routing protocol (thus the name ‘Protocol Independent’). PIM is designed to use the existing routing tables as provided by the unicast routing protocol to make its multicast routing decisions.

PIM was defined by the Internet Engineering Task Force and is an open standard. Since I have not worked with PIM on any platform other than Cisco, I won’t attempt to cover differences in implementation.

PIM has two typical modes of operation: Sparse and Dense. It’s difficult to really explain these well in a few words, so I will only say this: Dense mode floods traffic out until other routers tell it to stop, while Sparse mode only sends traffic when specifically requested. It’s an oversimplification, but think of Dense=more, Sparse=less.

Key Points Summary

We know that IGMP deals with multicast-enabled hosts on a LAN communicating with their router. IGMP=Host and Router. There are three versions of the IGMP protocol, with v2 being most prevalent, and v3 up and coming.

PIM deals with router-to-router communication. PIM relies on the underlying routing protocol (OSPF, EIGRP, etc) to be able to make its multicast routing happen. PIM=Router-to-Router.

Tune in Next Time

That is all for this installment. The next article will deal with IGMP and IGMP snooping more in-depth. After that, we’ll venture up the OSI stack and have a detailed look at PIM, SM and DM respectively.

For the most comprehensive IP Multicast for Cisco reference, look to Beau Williamson’s ‘Developing IP Multicast Networks, Volume 1’ from Cisco Press. It is absolutely required reading for the aspiring CCIE. If you have Cisco CCO access, locate the ‘Internetworking Technology Handbook’ and read the IP Multicast Chapter.

Filed Under: Featured, Routing, Switching Tagged With: , , , , , , ,

Top Five Most Interesting Network Virtualization Technologies of 2010

July 13, 2010 1 Comment
x
Bookmark
top 5 network virtualizationAuthor: Andres Villalva

Attending our weekly data center project meeting the other day, one of the network engineers was confronted with an incomplete action item against his name. He responded light heartedly by declaring that we were speaking to a ‘virtual instance’ of himself and that this particular instance had been assigned limited resources to complete this task.

Once upon a time, this geeky virtualization humor was the sole domain of VMWare administrators but today network engineers all over the world are faced with the challenge of adapting to the concepts of virtualization.

You might argue that Virtual LANs and Virtual Private Networks have been commercially popular for well over a decade. But there is a new wave of virtual network concepts knocking on the door of the network engineer’s standard skills arsenal and this time the virtualization goes way beyond adding layer 2 headers.

The following are my top five most interesting network virtualization technologies of 2010. Some are old hat and some have recently been released, but they all fall under the banner of the new age network virtualization.

#1 – MPLS VPN.

Multi Protocol Label Switching VPN is used to transport multiple customers over the same physical infrastructure with the added feature of keeping each customers routing tables isolated. This is achieved by pre-pending a 64 bit route distinguisher to an IPv4 address to create a unique VPNv4 address. One of the key concepts of this technology is that VPNv4 addresses are not IP addresses and are propagated across the network using Multiprotocol BGP (MBGP) via the VPNv4 address family.

Such is the recent growth of this technology that Cisco have introduced it to the CCIE curriculum.

#2 - VRFs

Virtual Routing and Forwarding allows one router to maintain several separate instances of a routing table. Conceptually, it is not the control plane that is virtualised – it is the data plane that is virtualised allowing forwarding decisions to be segregated based on customer or any other administrative grouping required by the network engineer. VRFs generally go hand in hand with MPLS VPN although they can be used separately without any problems. VRF lite, for example is a description of the Virtual Routing and Forwarding technology being used without MPLS VPNs.

#3 – VDCs

A VDC (Virtual Device Context) is the new technology currently released on the Cisco Nexus 7000 series switches.

A VDC allows one physical switch to be logically segmented into up to four virtual switches. Just like any virtualization concepts, there is a layer of abstraction between the physical switch and the presentation of the virtual switches. In addition to the virtual segmentation that can also be achieved by VLANS, VDCs provide a layer of administrative control over the entire virtual switch making it a more flexible option for hardware resource sharing accross departments or organizations.

#4 – VPCs

A VPC (Virtual Port Channel) is an etherchannel that consists of bundled links terminating across two different peer switches. It is a way of providing redundant links without invoking a spanning tree blocked port on one of the paths. And it has the added benefit of etherchannel load balancing algorithms to distribute the outbound load more evenly.

#5 – Virtual Switch

Virtual Switches are not new to VMWare administrators but they are to network administrators. Cisco’s Nexus 1000V is a Cisco-fied virtual switch that adds advanced functionality and a CLI to the existing VMWare virtual switch product. It contains many of the features that you would expect from a Cisco switch such as Private VLANs, TACACS authentication and even ACLs. It also features some cool virtual switch specific functionality such as vMotion awareness.

But the news is not all rosy for the die hard Cisco experts. The Nexus 1000V does require a good level of virtualization understanding in order to configure. In fact, the control plane and switch management is actually achieved using a Virtual Machine so it is important to have VMWare skills on hand to manage this system.

*********

Advancing your IT career? IT-Pathways.com is a leading Information Technology career development website. Find IT Cover Letters, IT Resumes, Training, Interview Tips and lots more written by colleagues in the industry

Filed Under: Featured, Switching Tagged With: , , , , , , , , , , , , , , , ,

DHCP Snooping: Keeping Those Rogues in Check!

July 1, 2010 2 Comments
x
Bookmark
dhcp snoopingAuthor: Jake Gillen

Using DHCP Snooping to detect unwanted DHCP servers

If you have been a network engineer for a while, you have undoubtedly heard about, or experienced first hand, a rogue DHCP server and the havoc it can wreak on a LAN. When I say ‘rogue’, I am referring of course to an unauthorized, untrusted and unwanted DHCP server that appears on your network and starts handing out IP addresses that it has no business handing out.

I experienced this a lot in the late 1990s, when Linux was first making its appearance on the scene. Various Hackers and Hobbyists would bring their personal Linux boxes to work (a big NO NO) and plug them in to the network. At that time, it is my understanding that many flavors of Linux came equipped with a running DHCP server right out of the gate.

More than a few times, the NOC I was working for would get a call about a host (usually a Windows laptop) that was using DHCP and getting an address that was not working (RFC 1918 addresses typically). Armed with our trusty (but heavy) Sniffer, we would set up our SPAN port and find the offending Linux machine by the MAC address, and there was much rejoicing.

DHCP snooping to detect accidents

It is important to note that these rogue DHCP servers were accidental, and not of the Wily and Evil Black-hat variety. Regardless of intent, Cisco seemed to recognize the issue, and introduced the feature (and, finally, the point of this article!):

DHCP Snooping.

Cisco says that DHCP Snooping is a DHCP feature that provides security by filtering untrusted DHCP messages from hosts and/or other devices in the network. DHCP Snooping accomplishes this level of security by building and maintaining a DHCP Snooping table.

If you are not familiar with DHCP and its inner workings, there are a ton of great references on the Webs; I won’t even attempt to go into great detail on it. For our purposes, DHCP is a protocol (first described in RFC 1123) that allows for central management and allocation of IP addresses to hosts.

One key thing to remember is that DHCP messages won’t be forwarded out of a LAN (via a router interface, VLAN interface etc), unless a DHCP Relay is configured. In the Cisco world, a DHCP relay is configured using IP helper addresses. Helper addresses direct the requests to DHCP servers that are not local to the host.

So, back to DHCP snooping.

The first step: A host decides that it needs an IP, and sends out a DHCPDISCOVER to the IP address 255.255.255.255. The host uses its own physical address as a DHCP client ID. You’ll notice the destination IP is all 255. This broadcast is used so that the host doesn’t need to know the anything about the network to which it is connected (sometimes called a ‘limited broadcast’).

When that host sends out the DHCPDISCOVER message, all hosts on its local network see the message and if they are not DHCP servers, they take no action. When the router for the network sees the message, if IP helper addresses are defined, it forwards the message on, and the host gets its IP and all is well. If there happens to be a DHCP locally, either by design or by accident, there is a really good chance that the host is going to end up the IP from that local server, which could just possibly be up to no good.

Most of the attacks that I am aware of that leverage DHCP as an attack vector are Denial of Service (DoS) attacks, referred to as ‘DHCP Exhaustion’ attacks. New hosts can’t get IP addresses if the range is exhausted, and things tend to grind to a halt.

Configuring basic DHCP snooping on a switch is fairly simple.

For an IOS-based switch:
Dadren3560(config)#ip dhcp snooping !(globally enabled)
Dadren3560(config)#ip dhcp snooping vlan 100 !(actively snooping on VLAN 100)
Dadren3560(config)#interface gi 0/52 !(Uplink port to router)
Dadren3560(config-if)#ip dhcp snooping trust !(Messages destined for DHCP server use this port)

For your basic DHCP snooping configuration, that is all there is! It is VITAL to remember that you must set a port as ‘trusted’ if you wish that port to be used to reach a legitimate DHCP server.

In this case, my 3560 is connected to a 6509 switch, and that is where the IP helper addresses are configured. So, I trusted the port that I would expect DHCP messages on. All of the rest of the ports (access ports in this case) are now untrusted and can not respond to DHCP requests.

You can configure ‘OPTION-82’ if your DHCP server supports it (mine doesn’t). Be advised that the default for ‘OPTION-82’ is on, and you’ll need to turn it off if your server does not use it:


Dadren3560(config)# no ip dhcp snooping information options

Now that you have all of this configured, you can use ‘show’ commands to view the DHCP snooping binding table, and to display your DHCP snooping configuration.


Dadren3560# show ip dhcp snooping binding
Dadren3560# show ip dhcp snooping

DHCP snooping may not be something that you need in your environment. However, if you’re like me, you’ll take the time to do the configuration as a preemptive measure against the possibility.

Also, I highly recommend that you ‘Lab It Up’ before implementing. Configure, run your debugs, take sniffs, get a better understanding what is going on behind the scenes, and do your DUE DILIGENCE. Always use your ‘show’ commands. When in doubt, err on the side of caution and get help (TAC, Forums, co-workers).

Remember: The only stupid question is the one left unasked!

References:
http://www.cisco.com/en/US/customer/docs/switches/lan/catalyst3560/software/release/12.2_40_se/configuration/guide/swdhcp82.html#wp1151921

Have any questions about this post?  Leave a comment below about dhcp snooping and let us know what your think!

Filed Under: Featured, Switching Tagged With: , , , , , , , , , , , , , , , , , , , , , , ,

EtherChannel Configuration – Cisco WS-X6148A-GE-TX Over-Subscription

February 9, 2009 Leave a Comment
x
Bookmark

etherchannel configurationHere's an issue than can occur when configuring EtherChannel on a 6500 series switch.

So here's the scene. You have an uplink that is constantly getting saturated due to backups (or whatever) and you need more than a Gigabit of throughput so that your network won't be congested. No worries, you need to create an Etherchannel to bundle multiple Gig interfaces together and increase your throughput. So you put in your change request and sit down to create your EtherChannel.

As you add you physical ports to the channel group you notice the switch is throwing the following error:

CAPI_EC-4-GROUP_RATE_LIMITED: Adding interfaces of the same port-group (1-8) on WS-X6148A-GE-TX to an Etherchannel will not increase the channel throughput!

Crap! What does that mean?!?!

Well what is going on is this. Cisco like many other hardware manufacturers built their FastEthernet modules on the assumption that not every port on the FastEthernet 10/100/1000 module will be sending and receiving a full Gigabit of traffic at the same time. So like an Airliner, they over-subscribe the card. They engineer it so that every 8 ports are controlled by a single ASIC connecting them to the switch fabric. That ASIC connection to the switch fabric is only a Gigabit of throughput.

So here's a big NOTE when planning your EtherChannel Config: When setting up EtherChannel on copper Gigabit modules ensure that the module is not oversubscribed. For example, a Cisco WS-x6148 48 port 10/100/1000 Ethernet module for the 6500 series switch is oversubscribed. It will throw an error when trying to configure Etherchannel across any contiguous 8 ports.

From Cisco's Website:

CAPI_EC-4

Error Message CAPI_EC-4-GROUP_RATE_LIMITED: Adding interfaces of the same port-group
([dec]-[dec]) on [chars] to an Etherchannel will not increase the channel
throughput!

Explanation This message indicates that ports on the indicated slot use over subscription causing the total throughput of the port channel to be limited by port-group.

Recommended Action If more throughput is required, either use ports from a card that does not use over subscription, or use ports from different cards or port-groupings on oversubscribed cards. For example, if the card has 48 ports in groups of eight, you can select ports 1, 9, 17, 25, 33, and 41 for the same port-channel.

So to alleviate this make sure you are using a WS-X6548 or better yet a WS-X6748 module. You will then be on your way to EtherChannel bliss and be forwarding packets like a banshee in no time!

FREAK!!

Filed Under: Switching Tagged With: