Guide: Building a Self-Contained Virtual Steelhead Lab – Part 2

Note: This post carries on from Part 1.

VLANs

SW1 and SW2 have been used to allow multiple devices to connect to the VSH’s Primary, Auxiliary and lan0_0 subnets. You can either use trunk ports or access ports between the switches and R3 and R5. If using access ports, you’ll need a total of six ports per switch:

SW1

Switch Port #: VLAN: Connects to: Description:
1 VLAN 2 VSH-A Primary interface VSH-A Primary Interface VLAN
2 VLAN 2 R3, Fa0/0
3 VLAN 3 VSH-A Auxiliary interface VSH-A Auxiliary Interface VLAN
4 VLAN 3 R3, Fa0/1
5 VLAN 4 VSH-A lan0_0 interface VSH-A lan0_0 Interface VLAN
6 VLAN 4

R3, Fa1/0

Continue reading

Guide: Building a Self-Contained Virtual Steelhead Lab – Part 1

A little while back I began looking into WAN optimisation, and in particular, Riverbed’s Steelheads. I really enjoyed all that I was reading so decided it was time to fire up a few Virtual Steelheads in my lab. As was the case in my Connecting the NetApp Simulator to your Virtual and Physical Labs and Trunking VLANs between the NetApp Simulator and GNS3 posts, GNS3 again plays an instrumental part in getting this lab up and running.

The reason why I have called this a “Self-Contained” lab is because, as you will soon see, it demonstrates you how can replicate a real-life setup using a single PC or laptop with the following applications:

  • GNS3 (installed on your PC)
  • VMWare Workstation (installed on your PC)
  • Two Windows VMs (running in Workstation)
  • Two ESXi hosts (running in Workstation)
  • Two Virtual Steelheads (one installed per ESXi host)

(With all of this virtualisation inside of virtualisation taking place, I can’t help but think about the movie Inception) :)

Background

Before jumping into the configuration details, I’ll run through a few things which you will need to know in order to complete the setup.

Continue reading

Trunking VLANs between the NetApp Simulator and GNS3

In my previous post Connecting the NetApp Simulator to your Virtual and Physical Labs, I explained the steps you need to follow in order to connect the NetApp simulator to GNS3. By doing this you’re able to connect the simulator to Cisco routers, Virtual Steelheads, ASA firewalls, F5 load balancers… to put it simply, just about any physical or virtual piece of equipment you can think of! This entry builds on that post and demonstrates how, with just a few extra steps, you’re able trunk VLANs between the simulator and GNS3.

To demonstrate its capabilities, I’ll explain three different methods GNS3 is able to handle the VLANs which are passed to it by the simulator. (Note that additional methods become available when you integrating other appliances into GNS3. For example, you could have the simulator hand off the VLANs to a Palo Alto firewall).

Creating VLANs & LIFs on the Simulator

Let’s begin by configuring the simulator side. We’ll need to create the VLANs and LIFs which we plan to make accessible to the device(s) in GNS3. For this example I’ll configure them in the following way:

  • e0d-20 = 10.0.20.9 /24
  • e0d-30 = 10.0.30.9 /24
  • e0d-40 = 10.0.40.9 /24

Continue reading

Connecting the NetApp Simulator to your Virtual and Physical Labs

I have written a few pieces on making the most out of your virtual and physical labs. These include:

Today I’m going to cover how you can add another piece of virtual equipment to your lab – the NetApp Simulator.

Note: As there are plenty of NetApp Simulator documents, blog posts and forum discussions, I won’t be covering things like licence keys, initial configuration, etc.

Overview

As with my previous guides, GNS3’s “cloud” object is used to enable the simulator to connect to the rest of the lab virtual and physical lab. For those who are unfamiliar with the cloud object, it allows you to bind your network adapters (both physical and virtual) to an object inside of your GNS3 topology. This object can then be connected to your GNS3 equipment and/or other clouds, enabling the devices to communicate with one another.

Continue reading

Shape Average Vs Shape Peak – Part 3

In my previous post in this series I covered the difference between Shape Average, Shape Peak and Shape with no Excess. Now that that’s out of the way, let’s get down to configuration examples. I’ll use similar specifications to the ones I used last time:

  • CIR = 512kbps (512,000 bps)
  • Bc = 5,120 bps
  • Tc = 10ms (0.001 seconds)
  • Be = 5,120 bps for Shape Average and Shape Peak. (Shaping with no Excess will be covered in my next post).

Shape Average

Below is a basic Shape Average policy map with a 512kb shaper applied.

R1(config)#policy-map ShapeAverage-512k
R1(config-pmap)# class class-default
R1(config-pmap-c)#shape average 512000
R1(config-pmap-c)#interface fa0/0
R1(config-if)#service-policy output ShapeAverage-512k
R1(config-if)#do sh policy-map int f0/0

 FastEthernet0/0

  Service-policy output: ShapeAverage-512k

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval  Increment
             Rate           Limit  bits/int  bits/int  (ms)      (bytes)
           512000/512000    3200   12800     12800     25        1600

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      0         0         0         0         0         no

Continue reading

EIGRP No Auto Summary Command, Part 2

A few years ago I wrote a blog post about EIGRP and the “auto-summary” command called EIGRP No Auto Summary Command, Part 1. In that post I provided a brief description of what “auto-summary” does and demonstrated how it works by creating a basic lab. Now that you’ve seen the basics though, it is time to dig a little deeper.

In the previous post we saw that R1 and R2 were both automatically summarising the 10.45.100.0/24 and 10.16.0.0/24 networks respectively and therefore R3 and R4 could not reach one another. That’s seems normal enough seeing as though the command is called “auto-summary”. However, things aren’t that simple unfortunately.

For example, take a look at this topology:

topology

Both routers are running EIGRP, but only R1 has the “auto-summary” command enabled, as per the configurations below:

Continue reading

MTU Vs MSS – Part Two

A little while back I posted an entry called MTU Vs MSS – Part One. At the time the plan was to follow it up with Part Two a short time later, however, here it comes over a year late :) I do apologise for that.

What prompted me to get back to writing Part Two was an e-mail from a reader who asked how I came to the conclusion that using the “ip tcp adjust-mss” command affects a SYN packet’s MSS regardless of whether it is applied to the inbound or outbound interface. The reader also asked if I have any links to documentation that describes this. The way in which I came to the conclusion was by labbing it up. Unfortunately though I do not have any documentation that backs me up.

This blog post will demonstrate the lab I used to come to the above conclusion.

Here is the topology that I used. I have marked each link with a letter to mark the points at which the proceeding packet captures were done. (Note that PC1 and PC2 are GNS3 routers with their icons changed).

topology

Continue reading

Understanding MQC, Part 3: Output Analysis

In my previous post I implemented a basic QoS configuration. In this post I will demonstrate how the “bandwidth” and “priority” commands treat their respective classes, as well as how to interpret the “show policy-map interface” command output.

Parent Shaper

Below is the output seen when the “show policy-map interface” command is issued. The Parent Policy’s class-default Class Map (at the top of the output seen below) represents all of the Child Class Maps’ counters put together.

For example, if 5 packets are dropped from the “MATCH-Voice” Class Map and 10 packets are dropped from the “MATCH-BulkData” Class Map, 15 drops will be shown under the Parent Policy.

Router#sh policy-map int gi 0/1
 GigabitEthernet0/1
  Service-policy output: PARENT-EGRESS-Shaper
    Class-map: class-default (match-any)
      1 packets, 68 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any 
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 2/158
      shape (average) cir 1024000, bc 4096, be 4096
      target shape rate 1024000
      Service-policy : CHILD-EGRESS-BandwidthAllocation
        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0
        Class-map: MATCH-BulkData (match-any)
          0 packets, 0 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match:  dscp af33 (30)
            0 packets, 0 bytes
            30 second rate 0 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0
          bandwidth 300 kbps
        Class-map: MATCH-Voice (match-any)
          0 packets, 0 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match:  dscp ef (46)
            0 packets, 0 bytes
            30 second rate 0 bps
          Priority: 150 kbps, burst bytes 3750, b/w exceed drops: 0

        Class-map: class-default (match-any)
          1 packets, 68 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match: any 
          
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 1/98

Continue reading

Understanding MQC, Part 2: Basic Configuration

In my previous post I mentioned the six steps which are required in order to implement a QoS solution. In this post I’ll use those steps to create an example implementation. Before I do though, I’ll first cover the “priority” and “bandwidth” commands.

Priority & Bandwidth Commands

In Step 3 of the process you must assign a a portion of bandwidth to the Class Map. The two main options used here are “priority”and “bandwidth”. Details on what each of them do can be found here.

In short though, the “priority” command is used for time sensitive applications where packets need to be sent ASAP, for example, VoIP calls. To ensure that these packets are sent as soon as possible, the router uses a special queuing process called Low Latency Queuing (LLQ) whereby all priority packets are sent immediately, even if there are other packets which on the router first.

The “bandwidth” command is used for non-time sensitive traffic, such as large file backups.

Continue reading