September 3, 2010

IP Multicast for the Intimidated, Part 2: IGMP

August 17, 2010 Leave a Comment
x
Bookmark

ip multicastIn my last post, the first in a series about IP multicast, I tried to make the subject as painless as possible. You see, it’s been my experience that a great many network engineers get very nervous when faced with the prospect of having to work on IP multicast. Why? My guess is that it’s a matter of familiarity and practice. Familiarity is gained through education on the subject and hands-on, deliberate practice.

This post is dedicated to the Internet Group Management Protocol, or IGMP. IGMP v2 is an IETF standard defined in RFC 2236 (v3 is defined by RFC3376). When I refer to IGMP in this post, I am referring to Version 2, and I will annotate when I refer to Version 1 or 3 respectively.

Let’s start at the beginning: IGMP v1 had only two message types, a membership query and a membership report. A host would send out a membership report when it was interested in a particular group, and the router would send out a membership query when it wanted to know if hosts on the LAN were still interested in receiving a group.

This version was not able to efficiently or quickly determine when hosts on the LAN no longer wanted to receive a certain group; the router would send out membership queries for a specific group, and if there was no reply from any of the hosts after three consecutive queries, the router would stop forwarding. That’s pretty wasteful of router CPU cycles.

Since efficiency is a central them in multicast, a new version, v2, was born and set out into the world in RFC2236. Version 2 has four IGMP messages: membership query, version 1 membership report, version 2 membership report, and leave group.

The membership query message is unchanged, with the router sending out the message verifying that at least one host is still interested in each specific group. If multiple hosts on the LAN respond, the router doesn’t listen to any of the responses but the first one it receives. As long as one host is still interested, the group is active on the router.

The membership reports allow the hosts to specify which version (1 or 2) they ‘speak’. This is a backward compatibility function, since some hosts on the LAN might not have gotten the memo about the new IGMP version.

The message that comprises the biggest difference in v1 and v2 is the leave message.

In IP multicast, there are two really important messages, called joins and leaves. You will see these terms a lot, and not only in relation to the IGMP protocol, but also when looking at PIM on a router.

In IGMP v2, the addition of the leave message is in place to reduce the latency between when the last host on a LAN stops wanting to receive traffic from a specific group, to when the router stops forwarding the traffic for that group. You’ll recall that the router waits three consecutive query message cycles before discontinuing forwarding for a specific group. With the leave message, hosts on the LAN can now tell the router that they are not interested in receiving traffic from a specific group any longer. The router, in turn, sends out a group-specific membership query to the LAN, and if no other hosts respond that they still want the group traffic, the router times out the group immediately and the unwanted traffic stops being sent. That’s way more efficient, right?  I agree!

IGMP v3 is out there, but I have to be honest here in the interest of full disclosure: I have not used it or worked with it yet.

IGMP v3 adds some majorly cool functionality, in that the host on the LAN can now send a message to the router specifying not only from which group it wants to receive traffic, but also what SOURCE HOST it wants to receive that traffic from.  This is referred to as Source-Specific Multicast (SSM) and it is a really major step in the efficiency and even security of IGMP. Being able to say ‘I want that traffic from that source’ is really pretty different from the best-effort nature of IP multicast.

Again, in the interest of full disclosure, I have to admit that I have no idea about what the implementation of IGMP v3 would entail in my network, which is all IGMP v2 (and humming along nicely!).

An unfortunate default behavior of a LAN switch, after all this work to make IGMP efficient, is to flood all the ports on the same LAN with multicast traffic. That is wasteful and undesirable, and leads us to our next topic: IGMP snooping.

ip multicast

IGMP snooping requires the LAN switch to look into each multicast packet and ascertain which host on the LAN is asking to receive which group from the router. The LAN switch can then associate the host’s port to the group it is receiving traffic from. This stops the flooding of the multicast traffic to the rest of the hosts on the LAN.

Beware though: IGMP snooping is processor intensive and can easily cause severe performance issues on lower-end switches.

So, there you have the very over-simplified, high-level view of IGMP. Remember that leave messages are central to IP multicast, and that they are the main enhancement added in IGMP v2. IGMP snooping can be a good thing on a LAN switch, but can also add its own problems by taxing the switch’s resources.

As always, please lab it up if you have questions, and your mileage may vary!

See, that wasn’t so bad now, was it?

Filed Under: Configuration Tips, Featured Tagged With: , , , , , , , , ,

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: , , , , , , , , , , , , , , , , , , , , , , ,

Understanding Network Routing Protocols

April 13, 2010 Leave a Comment
x
Bookmark

network routing protocolsNetwork Routing Protocols - IGRP, EIGRP, OSPF, ISIS, BGP

By Shaun Hummel

Overview

The purpose of routing protocols is to learn of available routes that exist on the enterprise network, build routing tables and make routing decisions. Some of the most common routing protocols include RIP, IGRP, EIGRP, OSPF, IS-IS and BGP. There are two primary routing protocol types although many different routing protocols defined with those two types. Link state and distance vector protocols comprise the primary types. Distance vector protocols advertise their routing table to all directly connected neighbors at regular frequent intervals using a lot of bandwidth and are slow to converge. When a route becomes unavailable, all router tables must be updated with that new information. The problem is with each router having to advertise that new information to its neighbors, it takes a long time for all routers to have a current accurate view of the network. Distance vector protocols use fixed length subnet masks which aren't scalable. Link state protocols advertise routing updates only when they occur which uses bandwidth more effectively. Routers don't advertise the routing table which makes convergence faster. The routing protocol will flood the network with link state advertisements to all neighbor routers per area in an attempt to converge the network with new route information. The incremental change is all that is advertised to all routers as a multicast LSA update. They use variable length subnet masks, which are scalable and use addressing more efficiently.

Interior Gateway Routing Protocol (IGRP)

Interior Gateway Routing Protocol is a distance vector routing protocol developed by Cisco systems for routing multiple protocols across small and medium sized Cisco networks. It is proprietary which requires that you use Cisco routers. This contrasts with IP RIP and IPX RIP, which are designed for multi-vendor networks. IGRP will route IP, IPX, Decnet and AppleTalk which makes it very versatile for clients running many different protocols. It is somewhat more scalable than RIP since it supports a hop count of 100, only advertises every 90 seconds and uses a composite of five different metrics to select a best path destination. Note that since IGRP advertises less frequently, it uses less bandwidth than RIP but converges much slower since it is 90 seconds before IGRP routers are aware of network topology changes. IGRP does recognize assignment of different autonomous systems and automatically summarizes at network class boundaries. As well there is the option to load balance traffic across equal or unequal metric cost paths.

Characteristics

· Distance Vector

· Routes IP, IPX, Decnet, Appletalk

· Routing Table Advertisements Every 90 Seconds

· Metric: Bandwidth, Delay, Reliability, Load, MTU Size

· Hop Count: 100

· Fixed Length Subnet Masks

· Summarization on Network Class Address

· Load Balancing Across 6 Equal or Unequal Cost Paths ( IOS 11.0 )

· Metric Calculation = destination path minimum BW * Delay (usec)

· Split Horizon

· Timers: Invalid Timer (270 sec), Flush Timer (630 sec), Holddown Timer (280 sec)

Enhanced Interior Gateway Routing Protocol (EIGRP)

Enhanced Interior Gateway Routing Protocol is a hybrid routing protocol developed by Cisco systems for routing many protocols across an enterprise Cisco network. It has characteristics of both distance vector routing protocols and link state routing protocols. It is proprietary which requires that you use Cisco routers. EIGRP will route the same protocols that IGRP routes (IP, IPX, Decnet and Appletalk) and use the same composite metrics as IGRP to select a best path destination. As well there is the option to load balance traffic across equal or unequal metric cost paths. Summarization is automatic at a network class address however it can be configured to summarize at subnet boundaries as well. Redistribution between IGRP and EIGRP is automatic as well. There is support for a hop count of 255 and variable length subnet masks.

Continue reading »

Filed Under: Featured, Routing
« Older Posts