Some of you have noticed that I've started using new icons in my topology drawings lately. I recently discovered a wealth of impressive Visio shapes provided for free by the good folks at VSD Grafx, who do custom Visio shape development. They offer three identical sets of 110 generic network shapes (one set each in blue, green, and grey) of impressive quality. Here are just a handful.

These shapes are 100% vector images, meaning that they scale perfectly to any degree.

Although they aren't typically of use for topology drawings, VSD Grafx also offers stencil sets of true-to-life shapes of everything from desktop printers to a conference room complete with faceless attendees. The quality of these shapes is nothing short of amazing. Included below are just a few random samples.

The stencil sets are available at VisioCafe: just grab the full set .zip file to get all of them.

Now that the community lab has been equipped with a Catalyst 3560, I have finally been able to write about private VLANs (which are supported only on Catalyst 3560 and higher switches). This article discusses the concept of private VLANs and includes a basic configuration example, with more complex configurations deferred for future articles.

Private VLANs were developed to provide the ability to isolate end hosts at layer two. To understand the motivation behind this feature, consider a colocation environment in which the network operator must connect servers belonging to different customers to the Internet. These servers must all be able to reach their first-hop router, but for security reasons, servers belonging to one customer must not be able to communicate with servers belonging to another. An obvious design solution for these requirements is to place each customer's servers in a separate VLAN, which also requires the assignment of a separate IP subnet per customer (even if they have only one server).

This approach wastes both VLAN IDs and IP address space. Private VLANs were introduced as a more elegant alternative, allowing multiple devices to reside in the same IP subnet, yet remain isolated from one another at layer two.

One thing that irked me when learning Visio 2010 was the mysterious disappearance of the object behavior dialog. The behavior dialog is useful for modifying, well, the behavior of elements within Visio (e.g. which lines show line jumps and what those jumps look like). In previous versions of Visio, it had been accessible via the right-click context menu (after selecting a line or shape) as Format > Behavior.... Alas, this option has disappeared from the context menu in Visio 2010.

In fact, upon initial inspection it appears to have been removed from the application entirely. Only after a good deal of searching did I uncover its hiding place: the developer menu. The developer menu is, of course, disabled for a default installation of Visio. To enable it, select the File tab and click Options. Under the Customize Ribbon heading, click the Developer tab checkbox to enable the developer toolbar.

You should now see a developer tab at top which displays the developer toolbar, complete with a button for the behavior dialog under the Shape Design section.

A while back, I wrote about Remotely-Triggered Black Hole (RTBH) Routing. The basic implementation we examined there is destination-based: traffic can only be discarded based on destination IP addresses. As several commenters pointed out, this is approach is limiting. While it allows for efficient traffic filtering, it is often more desirable to block only traffic originating from certain source address ranges rather than all traffic intended for a single destination. In this article we'll see how we can extend the RTBH concept to filter against source addresses as well.

The key component of source-based RTBH (S/RTBH) is the addition of Unicast Reverse Path Forwarding (uRPF). (For an example of how uRPF might be employed in its own right, check out Using uRPF at the access layer to deter DDoS attacks.) uRPF is discussed in RFC 3704 (BCP 84), and is essentially this: The source address of an incoming packet is looked up in the FIB. If there is a FIB entry for the address pointing out the interface on which the packet was received, the packet is allowed to pass. If not, the packet is discarded. (uRPF loose mode requires only that an entry matching the source IP address exists; it does not care whether the outgoing interface matches.)

We can combine uRPF with RTBH to filter against source IP addresses.

DHCP snooping is a feature which allows a Cisco Catalyst switch to inspect DHCP traffic traversing a layer two segment and track which IP addresses have been assigned to hosts on which switch ports. This information can be handy for general troubleshooting, but it was designed specifically to aid two other features: IP source guard and dynamic ARP inspection. These features help to mitigate IP address spoofing at the layer two access edge. I've already covered IP source guard (with and without DHCP), so today we'll look at how to implement dynamic ARP inspection.

Suppose a router receives a packet destined for the IP address 192.0.2.73. The router has in its routing table the following three routes:

To which next hop address will the packet be routed?

Last month, the prior generation of CCNP certification exams was officially obsoleted. Candidates now must pass the three new exams to earn their certification: ROUTE, SWITCH, and TSHOOT. Cisco Press publishes two series of study guides pertaining to these exams: the Official Certification Guides (abbreviated in this article as OCG) and the Foundation Learning Guides (FLG). On their faces, both appear to cover the same material. Which one should you choose?

This isn't a certification blog, and I assure you that I have absolutely no intention for it to become one. However, as this seems to be a confusing issue in the community, I decided to put my Safari subscription to use and review the ROUTE book from each series side by side.

As you read, please keep in mind that I have not taken the ROUTE exam; I am reviewing these books from the perspective of a certification candidate. Further, I am reviewing only the ROUTE book from each series; I ask readers to refrain from forming assumptions about the entirety of either set from the conclusions reached in the article.

EIGRP routers know only of routes advertised by directly adjacent neighbors because EIGRP is a distance vector routing protocol. When a destination network is removed from the EIGRP topology, a router initiates a route querying process in an attempt to locate a different route to that destination. As it is preferable to avoid this querying process, EIGRP routers will opportunistically store backup routes, known as feasible successors, when certain requirements are met.

To understand the concept of a feasible successor route, we must first understand what a successor is. The term successor can be defined as "one thing that succeeds another." In IP routing, this simply refers to the next-hop of the best route. A feasible successor, therefore, is not our current best route, but one which could be used in the event our successor route disappears.

An EIGRP router advertises each destination it can reach as a route with an attached metric. This metric is called the route's reported distance (the term advertised distance has also been used in older documentation). A successor route for any given destination is chosen as having the lowest computed feasible distance; that is, the lowest sum of reported distance plus the cost to get to the advertising router.