This post is going to provide a very basic introduction to configuring VRFs on Cisco IOS and Juniper's Junos. There's so many configuration combinations and options for virtual routing that it would be impossible to go through everything in great detail. At the end of the post I'll provide links to documentation where you can get detail if you want it.

Here's a summary of interesting articles/posts that I've come across in the last couple of weeks.

All network engineers should be familiar with the method for virtualizing the network at Layer 2: the VLAN. VLANs are used to virtualize the bridging table of Layer 2 switches and create virtual switching topologies that overlay the physical network. Traffic traveling in one topology (ie VLAN) cannot bleed through into another topology. In this way, traffic from one group of users or devices can be kept isolated from other users or devices.

VLANs work great in a Layer 2 switched network, but what happens when you need to maintain this traffic separation across a Layer 3 boundary such as a router or firewall?

The last time I upgraded Net-SNMP it wasn't reporting the hrSystemProcesses OID. I wrote about that here. This time around I've upgraded to v5.7 and discovered two issues so far.

I read two interesting articles on VTP (Cisco's VLAN Trunking Protocol) this week.

The first is an older article from networkworld.com that reminds us all that VTP clients are also capable of updating VLANs on the network, not just servers.

When I first heard that a VTP client can update a VTP server under the right conditions, I was frankly a non-believer. No way. I'd seen evidence to the contrary in several documents at cisco.com and in Cisco courses - but all the evidence was written, without my doing any experiments. So, I spent some time experimenting a few years ago, and found that it's true - clients can overwrite VTP server's VLAN databases.

This post is for anyone who administers a Juniper SSL VPN. I saw an issue in our environment recently that was created by an unexpected interaction between two different systems that were working to enforce our computer security policy. Because the way the systems were configured is pretty common and because the issue is not specifically warned against by Juniper, I'm going to share it here.

The OpenBSD SNMP MIBs are now updated to compile under OpenBSD 5.0. Full details of how to install and use the MIBs are on the SNMP MIBs page.

There is no functional change in this release.

Download: obsd-mibs50.tar

As usual, if you find OpenBSD valuable, please make a donation to the project as they are dependent upon donations to cover many of their costs.

The OpenBSD routing table can be carved into multiple virtual routing tables allowing complete logical separation of attached networks. This article gives a brief overview of rtables and explains how to successfully leak traffic between virtual routing domains.

If you're an IT professional you've probably been hearing a lot about cloud computing lately. I know I've sat through a number of seminars and sales pitches where people have been touting public cloud services on the merits of lower cost, reducing infrastructure and quicker implementation of services. However, I've noticed that almost none of these presentations discuss the increased reliance on Internet connectivity. With all the focus on the benefits of cloud computing, it's easy to forget that there has to be a trade-off. In order to offer reliable, quality access to public cloud services, your Internet connectivity likely needs some tuning.

I just upgraded a couple of machines to OpenBSD 4.9 and noticed the hrSystemProcesses OID was not being returned by Net-SNMP 5.6.1 (from the 4.9 ports/packages collection) .

joel@theta:~% snmpwalk -v2c -c public theta .1.3.6.1.2.1.25.1.6.0
SNMPv2-SMI::mib-2.25.1.6.0 = No Such Instance currently exists
    at this OID

I know for sure this worked on OpenBSD 4.8/Net-SNMP 5.4.2.1.

Turns out there is a bug in Net-SNMP 5.6.1 (bug 3166568) that's causing this. It's been fixed in their SVN tree. If you download this patch, place it into your ports/net/net-snmp/patches/ directory and recompile the port, you'll be good to go.