Identifying device vendors by MACPosted by stretch in Resources on Friday, 4 Jul 2008 at 3:03 a.m. GMTOne resource I've found incredibly valuable in performing network reconnaissance is the IEEE's MAC OUI database. An Organizationally Unique Identifier (OUI) makes up the first 24 bits of a MAC address, and serves to identify the owner of an address range (typically the NIC manufacturer) with the goal of preserving global uniqueness. Although the IEEE's instructions state that OUIs should be entered in The database isn't always 100% telling, as the IEEE notes many manufacturers subcontract the production of interface circuitry, consequently delegating the assignment of burned-in addresses. However, the database has helped me numerous times to identify a rogue router emplaced by a customer or a legitimate infrastructure device which was overlooked in existing documentation and not otherwise remotely identifiable. Layer two protocol tunnelingPosted by stretch in Networking on Wednesday, 2 Jul 2008 at 1:56 a.m. GMTNormally, Cisco switches intercept and process a number of layer two protocols, including CDP, STP, VTP, and others. This can present problems when attempting to make a switch appear completely transparent, as is a common goal of service providers. Full transparency can be achieved with layer 2 protocol tunneling (not to be confused with L2TP). Switches can be configured to forward CDP, STP, and VTP frames instead of intercepting them. The command to enable basic L2 tunneling is The switch will transparently forward incoming CDP/STP/VTP frames out other similarly configured interfaces in the same VLAN. We can inspect the traffic statistics with Note the three seemingly useless lines at the end of the output. These lines present additional information when tunneling is expanded to include point-to-point protocols PAgP, LACP, and UDLD with the command The forwarding statistics now include all six protocols: My packets, let me show you themPosted by stretch in Announcements on Monday, 30 Jun 2008 at 12:59 a.m. GMTEarlier this month I mentioned the Wireshark wiki's capture page was a great place to find various packet captures, but it is sorely lacking in structure (not to mention security). Inspired, I decided to piece together my own capture repository. At the time of this writing, the archive contains fifty captures of various traffic types, with a heavy focus on routing protocols. Captures can be organized by category or included protocol, with a healthy amount of overlap. Many captures include a simple topology to aid in setting context (look for a 'view topology' link under each capture). An RSS feed lists the most recent captures, and leeching is supported. Yes, there are already places to find packets, like the aforementioned Wireshark wiki page or OpenPacket.org. But I wanted a structured, custom format with an emphasis on networking, not applications. This capture database was designed to serve as a reference, particularly to save engineers the hassle of setting up an entire lab merely to generate a protocol header. Hopefully people will find these captures useful. Let me know what you think! Please note that I am not currently accepting outside captures or requests for captures, although support is likely to be added in the future. I still have a quite a few captures to generate and upload, so be sure to check back once in a while. Adding columns to WiresharkPosted by stretch in Tips and Tricks on Friday, 27 Jun 2008 at 12:55 a.m. GMTWireshark is probably my favorite networking tool. Its value in troubleshooting the most peculiar network issues cannot be overstated, as it allows the engineer to analyze virtually every bit to traverse the wire. However, not many people realize its functionality can be customized to suite its operator's preference or situation. One of my favorite modifications is to add columns to the list pane, to provide quick access to statistics and packet attributes only otherwise available in the individual packet details. In addition to the default columns listing packet number, protocol, source and destination addresses, and so forth, Wireshark supports a plethora of other helpful details. Some of my favorites:
Consider the following capture of an OSPF adjacency being formed:
From the list view, it's not readily apparent which packets consume the most bandwidth. To add a packet length column, navigate to Edit > Preferences and select User Interface > Columns. Click New, and define the column's title. From the Format list, select Packet length (bytes). Use the up and down arrows to position the column in the list.
Click OK and the list view should now display each packet's length listed in the new column.
When does VLAN pruning occur?Posted by stretch in Networking on Thursday, 26 Jun 2008 at 1:04 a.m. GMTsgtcasey over on networking-forum.com recently posed in an interesting question: what triggers VLAN pruning? Specifically, will a switch only allow pruning of a VLAN from a trunk if it has no access ports configured for that VLAN? Or is it enough to have merely no active ports? Consider a simple trunking scenario:
Switch 1 is the VTP server, and has propagated VLANs 10, 20, and 30 to switch 2. The interfaces to which hosts A and B attach are configured as access ports in VLAN 10, and an 802.1Q trunk is formed between the two switches. By examining the trunk status on either switch we can verify that VLANs 1 and 10 are being passed while the others are pruned in both directions. Switch 2: When host B is disconnected, its interface on switch 2 becomes inactive. As switch 2 has no remaining active ports in VLAN 10, VLAN 10 becomes eligible for pruning. After roughly 30 seconds pass, we can see that switch 1 is now pruning VLAN 10 from the trunk (VLAN 10 is absent from the last line of the output): The VLAN remains unpruned on switch 2's end of the trunk, because it knows switch 1 still has at least one active port in VLAN 10: OSPF area typesPosted by stretch in Networking on Tuesday, 24 Jun 2008 at 12:31 a.m. GMTAdvancing from last week's discussion on OSPF network types, today's topic is a source of considerable confusion for many people new to OSPF: area types. Recall that a large OSPF domain is typically broken into separate areas to restrict the propagation of routes and reduce the amount of resources required by each router to maintain its link state database. Each area is connected to a central backbone, area zero. OSPF relies on several types of Link State Advertisements (LSAs) to communicate link state information between neighbors. A brief review of the most applicable LSA types:
LSA types 1 and 2 are found in all areas, and are never flooded outside of an area. Whether the other types of LSAs are advertised within an area depends on the area type, and there are many:
And I thought transfer caps were badPosted by stretch in News on Monday, 23 Jun 2008 at 8:35 a.m. GMTThe other day I came across an article discussing a series of ads put forth by cable companies with the intention of steering people away from Verizon's FiOS (a fiber to the premise service). It seems Comcast and Time Warner are trying to play on the fact that modern cable networks employ a hybrid fiber-coaxial distribution network to deliver service. This isn't a feature, but rather it is necessitated by the medium, particularly in this age of high-definition television. Typical cable company ambiguity, right? Curious, I located one of the ads on YouTube...
No. No, no, no, no, no, no, no, NO. You want to compare services? Let's talk about transfer speeds. Let's talk about the physical limitations of a shared medium. Let's talk about your impending transfer caps. 5 GB for $30 is such a bargain, after all! Oddly, none of this is mentioned by your constipated, know-it-all customer. Coaxial cable does not compare with the potential network throughput of fiber, and Verizon has the cable companies nailed to a wall with its FiOS service. I know this, and you know this, but the average consumer doesn't. And, sadly, many consumers are bound to get taken in by such misleading advertisements. Even the news article referenced above doesn't compare transfer speeds offered by the various providers. The good news is that Verizon has apparently taken some extent of legal action concerning these ads, as it should. Don't get me wrong, I'm not a Verizon evangelist by any means, but this slander piece by Time Warner is garbage and they know it. Tweaking the interface load intervalPosted by stretch in Tips and Tricks on Saturday, 21 Jun 2008 at 7:13 a.m. GMTBy default, the load for an interface is calculated over a five-minute interval. This is apparent from the output of a Of course, five minutes is an unacceptable length of time to idle while troubleshooting a critical link. Fortunately the window for statistics gathering is configurable with the To make computations more reactive to short bursts of traffic, you can shorten the length of time over which load averages are computed. If the load interval is set to 30 seconds, new data is used for load calculations over a 30-second period. This data is used to compute load statistics, including the input rate in bits and packets per second, the output rate in bits and packets per second, the load, and reliability. The load interval must be between 30 and 600 seconds, specified in increments of 30 seconds. Below we shrink the load interval to 30 seconds on the interface being monitored to achieve a reading much closer to real-time: OSPF network typesPosted by stretch in Networking on Thursday, 19 Jun 2008 at 3:38 a.m. GMTHaving worked almost exclusively with Ethernet transport my whole career, it took me a while to really grasp the concept of non-broadcast networks. Dynamic routing protocols, particularly OSPF, demand familiarity with all sorts of layer two topologies, so I knew I had to better educate myself on the matter. Fortunately, working with Dynamips and virtual frame relay networks provided the experience I needed to feel comfortable implementing all the different OSPF network types. OSPF addresses three classes of network (as listed in section 1.2 of RFC 2328): point-to-point, broadcast, and non-broadcast. Point-to-Point
This is by far the simplest network type, and serves as a convenient anchor from which to advance the discussion. A point-to-point network is, as its name aptly describes, a link between exactly two points (or routers). A packet sent from on of the routers will always have exactly one recipient on the local link. RSS feed now full-contentPosted by stretch in Announcements on Wednesday, 18 Jun 2008 at 3:43 p.m. GMTThe blog's RSS feed now features full-length posts, rather than merely the first few lines. Hopefully this will be more convenient for those following along via syndication. Thanks to tam for the suggestion! And yes, I'm aware of the irony of this post announcing the change being only a few lines itself. Using /31 subnets on point-to-point linksPosted by stretch in Networking on Wednesday, 18 Jun 2008 at 2:18 a.m. GMTA recent post on /30 and /31 addressing prompted one reader to ask when 31-bit subnet masks are appropriate, or supported. It turns out they've been supported for a while. Thirty-one-bit subnets were first proposed in RFC 3021, which was primarily motivated by the potential for public address space conservation. Recall that shrinking a /30 subnet to a /31 effectively doubles the number of point-to-point links you can address from a finite range. Cisco IOS has supported /31 subnets for point-to-point links since release 12.2(2)T. A thorough explanation of the feature is presented here. We can put this theory into practice by addressing a point-to-point connection between two routers as 10.0.0.0/31. Note that this even applies to Ethernet interfaces, technically a broadcast medium. An ominous warning message, no doubt, but it works just fine. We can successfully ping the far-end interface (10.0.0.1), and the subnet is accurately reflected in the routing table: How to ruin the InternetPosted by stretch in News on Monday, 16 Jun 2008 at 3:01 a.m. GMTThe New York Times published an article Sunday entitled Charging by the Byte to Curb Internet Traffic, discussing Time Warner's recent experiment with "Internet metering" and similar initiatives by Comcast and AT&T. These companies intend to implement data transfer caps for home broadband services, and to impose surcharges for excess traffic, to "ensure fair access for all users." From the article: One of them, Time Warner Cable, began a trial of "Internet metering" in [Beaumont, TX,] early this month, asking customers to select a monthly plan and pay surcharges when they exceed their bandwidth limit. The idea is that people who use the network more heavily should pay more, the way they do for water, electricity, or, in many cases, cellphone minutes. In that trial, new customers can buy plans with a 5-gigabyte cap, a 20-gigabyte cap or a 40-gigabyte cap. Prices for those plans range from $30 to $50. Above the cap, customers pay $1 a gigabyte. Plans with higher caps come with faster service. I feel ill. As an industry, I really hoped we had grown beyond such immature, underhanded grabs for a dollar. But the proposal seen here is a clear intention to undercut innovation for the sake of squeezing yet more profit out of an already inflated service. It has been known for years where the Internet is heading, and rather than grow their infrastructures to support increasing demands, these corporations saw fit to idle. As Internet service approaches a level of demand where it rivals the telephone, greed prevails and a new pricing structure is being eyed to wring the consumer's wallet even tighter. Decades ago, when mainframe computers were struggling to meet the needs of their users, did we simply decide to charge more for access? No, we built faster computers. Did we relent when 10 Mbps Ethernet wasn't fast enough? No, we developed technology to increase the speed, tenfold, again and again. This is the essence of technological evolution, and it is the catalyst which drives the advancement of society. A quote from the Times article illustrates how bandwidth caps stand in contrast to such progression: The Time Warner plan has the potential to bring Internet use full circle, back to the days when pay-as-you-go pricing held back the Web's popularity. In the early days of dial-up access, America Online and other providers offered tiered pricing, in part because audio and video were barely viable online. Consumers feared going over their allotted time and bristled at the idea that access to cyberspace was billed by the hour. Some other points to ponder:
Do the math. Consumers lose. An Illustrated Guide to IPsec by Steve FriedlPosted by stretch in Resources on Friday, 13 Jun 2008 at 1:10 a.m. GMTTo say IPsec is a complex technology is an understatement. ESP versus AH, tunnel mode versus transport, 3DES, AES, MD5, SHA -- there are quite a few pieces to the puzzle. It's taken me a while to get comfortable with IPsec in the Cisco world. Obviously studying for the ISCW furthered my knowledge considerably, but I owe a lot to Steve Friedl's Illustrated Guide to IPsec for laying the first foundations.
The author does an excellent job laying out the framework components and the advantages and drawbacks of varying implementations. Packet headers are illustrated in a very intuitive manner, demonstrating how the encapsulations work together to provide data authentication and encryption. Even if you're already well versed in IPsec theory, the guide provides a happily succinct overview of what can be a very daunting technology. If you're hungry for more after reading through the guide, check out my notes from the ISCW or the IPsec cheat sheet. /30 addressing shortcutPosted by stretch in Tips and Tricks on Thursday, 12 Jun 2008 at 12:13 a.m. GMTPoint-to-point IPv4 links are typically addressed with a 30-bit mask (255.255.255.252). This only provides 50% addressing efficiency (only two of the four addresses per subnet are usable), but many organizations consider this sufficient. Consequently, an engineer often needs to find the address of the interface at the other end of a /30 link to a neighboring router. You could do the binary in your head to deduce whether the local interface has the lower or higher IP, but an easier way is to remember this rule of thumb: the lower address will always be odd, and the higher will always be even. Consider a point-to-point link between routers A and B. You know the interface of router A is assigned 192.168.0.90/30. Router B's address is obviously one IP higher or lower -- but which is it? Since the local address is even, we know know we have the higher IP, and the other end of the link must be 192.168.0.89. Indeed, working out the binary will confirm that these are the two correct addresses for the 192.168.0.88/30 subnet. This same trick also works in reverse for /31 subnets, which are becoming more common as some legacy IP rules have been deprecated. For /31 subnets, the lower IP is always even, and the higher is always odd. For example, we know 192.168.0.176/31 is the lower IP in the pair, facing 192.168.0.177. (Note that these shortcuts only work on properly addressed networks.) CCIE scholarship by Internetwork ExpertPosted by stretch in News on Wednesday, 11 Jun 2008 at 12:26 a.m. GMTInternetwork Expert is sponsoring a "scholarship" for the CCIE exam. From the promotion: As part of Brian Dennis' and Brian McGahan's ongoing commitment to the CCIE community, Internetwork Expert is pleased to announce the Real CCIE's, Real People 2008 Scholarship. We will be choosing one U.S. scholarship recipient and one international recipient from the applicant pool. The scholarship recipients will each receive CCIE Lab training from start to finish including:
The only eligibility requirements listed are ability to travel and having passed (or even merely scheduled) the written exam. The deadline for applications is Friday, June |
Navigation
|
