Connecting Your Virtual IOS-XE and IOX-XR Lab To Your Physical Lab

I’ve been building and using virtual IOS images, such as IOS-XE (CSR1000v) and IOS-XRv for a while now. It’s been great to just spin up a lab, based upon what ever topology that I want, not have to worry about a mess of cables, or hear the mildly annoying hum of a rack of routers and switches running up my electric bill.

However, there are instances where running a physical lab makes sense. For example, the Cisco Switching images aren’t where they need to be to be able to simulate live environments. There are a host of quirks, from creating bridging loops easily and crashing the images to FHRP’s not having the desired functionality. Then there’s the aspect of only being able to run so many virtual images on a single computer. Every now and then, I want to create a larger topology. I already have four switches and ten routers, so why not integrate my virtual lab environment and physical lab environment?

Recently, that’s what I set out to do. I’m a Linux guy, so I’ve been using KVM as my hypervisor, for running my IOS images. I intended to continue doing that. The Linux computer that I’m currently running is Fedora 19. I know, I need to update it, but I’ve been too lazy to rebuild it lately. So, my examples are based on Fedora 19. If you’re running a newer version of Fedora (20, soon to be 21), CentOS 7, or even Ubuntu, you’ll need to modify your KVM configuration slightly. Ultimately, it should be compatible.

On my Fedora 19 computer, I’m using the qemu-kvm and openvswitch packages.

The first thing that you want to do is create a couple of init script for openvswitch. These scripts will allow you to create and tear down tap (virtual nics) interfaces, which your virtual IOS images will attach to on boot up.

Next, you need to create a bridge within openvswitch, and attach it to an unused physical nic. In my Fedora computer, I have my primary nic (p3p1), which is has the main IP Address that I use to access the computer remotely, then I have a secondary nic (enps4s0u1) that I’m allocating to openvswitch.

At this point, my physical nic, enp4s0u1, is already attached to a switch port on my physical lab. The switch port on the physical lab is in a trunking state. This is all you have to do for openvswitch, as it will automatically trunk the interface to the physical nic.

Next, It’s time to spin up my virtual IOS image. Here is my configuration:

On the first line, I simply tell KVM to create an instance with 2.5 GB of RAM and pointed to the image:

On the second line, I told KVM to create a serial connection and attach it to TCP port 8001 on the hypervisor. You can think of this as a console port on your physical gear.

The third and fourth line belong together. These two lines specify my MGMT interface on the IOS-XRv device, I’m attaching it to vlan 2, as my current lab Layer 2 management is on vlan 2. I’m also creating a tap interface called ‘tap8001’. Notice that the ovs-ifup and ovs-ifdown scripts are called to create and tear down the interface.

Finally, the last two lines create interface gig0/0/0/0 on the IOS-XRv image. On these two lines, I don’t specify to attach to any specific vlans, as I’ll be creating sub interfaces and creating a router on a stick. It also calls the ovs-ifup and ovs-ifdown scripts to create and tear down the tap interface ‘1g000’.

The config executes without any errors.

You can see that the ovs-ifup and ovs-ifdown scripts work as intended.

I’m also able to telnet to TCP port 8001 and gain access to the device.

From here, I can configure the device to participate in my existing physical lab. In this simple test, I’ll configure gig0/0/0/0.100 to connect to a physical router with the IP Address of 10.0.100.2, join OSPF, and MPLS LDP.

And there you have it. My virtual lab has successfully been integrated to my physical lab.

October 1, 2014

Posted In: CCNP SP Study Notes, IOS, IOS-XE, IOS-XR, KVM, Linux, openvswitch, Software Defined Networking, Virtualization

OSPF Area Types and LSA’s

Link State Advertisement (LSA) Types have never been my strong suite. I made a visual representation of how they are forwarded to help me get a better grasp on them.

OSPF Area Types

  • Default – This isn’t actually an LSA type. It’s meant to represent a default route.
  • Type 1 – Router Link – This is generated by a router and lists the neighboring routers and the cost of each router. This is only flooded within the area that the router interface exists in.
  • Type 2 – Network Link – This is generated by the Designated Router (DR). This lists all routers within an adjacent segment. This is only flooded within the area that the router interface exists in.
  • Type 3 – Network Summary – This is generated by an Area Border Router (ABR) and is advertised among all areas, except totally stubby areas and totally not-so-stubby areas.
  • Type 4 – ASBR Summary – This is generated by an ABR informing other areas that an Autonomous System Border Router (ASBR) exists within it’s network.
  • Type 5 – External Link – This is generated by an ASBR and is flooded within its area. ABRs will also flood their connected areas with this type 5 LSA informing other areas that external networks exist within its area.
  • Type 7 – NSSA External Link – This is generated by an ASBR participating in an not-so-stubby (NSSA) area. When the type 7 LSA reaches the ABR, It is converted to a type 5 LSA and forwarded to other areas informing them that an external network exists within its area.
  • When a type 5 LSA enters a stubby area, it’s entered into the RIB as a default route, striping the type 5 LSA routes. Type 5 LSAs are also not forwarded to not-so-stubby areas. To get external routes INTO an not-so-stubby area, the area has to be converted to a totally not-so-stubby-area, which will remove all summaries and inject a default route.

    As you can see from the diagram, above, there are six area types.

  • Backbone Area
  • Standard Area
  • Not-so-stubby Area
  • Totally stubby Area
  • Totally not-so-stubby Area
  • All areas have to be directly connected to area 0, which is the backbone area. All routers that exist within only area 0 or within just a single area are called backbone routers. Routers that connect to multiple OSPF areas are called ABRs. Routers that are connected to an OSPF area AND connected to an external routing protocol (EIGRP, ISIS, RIP, BGP, static routes, etc) are called ASBRS.

    Stubby areas and totally stubby areas are areas that have one way in and one way out of an area. That is, they can’t be connected to area 0 and any other area or external network at the same time, as a stubby and totally stubby area ABR will not forward type 5 LSAs to other areas. A totally stubby area will only have a default route injected into its network.

    Not-so-stubby and totally not-so-stubby areas can be connected to external networks and will forward the type 7 LSAs beyond their area. When the type 7 LSAs reach an ABR, the ABR will convert them to type 5 and forward them to the other areas.

    April 12, 2014

    Posted In: CCNP SP Study Notes, OSPF