Feb 21

What mode do I set my Ixia Netoptics iBypass to?

I was introduced to Netoptics iBypass switches years ago, but it wasn’t until recently that I had the chance to administer one. As a new product to me, I read the user manual to make sure the IPS was connected correctly to the monitor ports. I worked with the sales engineer to make sure I understood how to use the product.

At time of deployment, I set the Bypass Mode to “TAP”. I did this because the admin of the IPS wasn’t ready to start blocking traffic yet. I was to change it after he had a chance to collect data for a while.

When the IPS admin was ready to have me reroute traffic through the IPS, we ran into some problems. I found that when I made the change, data wasn’t rerouted through the IPS. I had read the manual on how to do this, but clearly I didn’t do it correctly. See the image below with the Bypass Mode definitions.


I found the definitions to be a little confusing. It was confusing to me because I didn’t know what the Netoptics definition of Bypass was. Bypass meant that the data was going to bypass the IPS or monitoring tool. I was thinking that Bypass meant that it was going to Bypass the normal data flow path. Due to this, I had put the iBypass switch into bypass mode instead of normal mode for the data to flow through the IPS.

After learning this, I was able to set the iBypass to “Fail-open”. This mode put the iBypass into normal mode… Normal mode meaning that it is rerouting traffic through the IPS. If the IPS failed, the iBypass would send the data through bypassing the failed IPS.

Here are my definitions of Ixia’s Netoptics iBypass modes.

  1. Tap – Copy the data and send it to the IPS.
  2. Fail-Close – Reroute traffic through the IPS, when the IPS fails, don’t send data through the iBypass.
  3. Fail-Open – Reroute traffic through the IPS, when the IPS fails, keep sending data through the iBypass.
  4. Force-Bypass-Off – Force traffic through IPS.
  5. Force-Bypass-On-Close – Stop rerouting traffic, block all traffic.
  6. Force-Bypass-on-Open – Stop rerouting traffic, allow traffic to pass.

So far my experience with the iBypass switch has been a positive one.

I hope this helps you new iBypass switch users out there.

Please feel free to share your comments below!




Feb 25

QOS on the 4500-E with IOS XE is different from the older 4500s.

For years I have configured QOS on Cisco switches. The 4500’s and 6500’s always caused me the most frustration. Depending on the line card, you may have 2 or 4 hardware queues with the Priority queue different on each platform. The 4500’s and 6500’s are different then the other Cisco platforms.

I recently had the privilege to setup a new 4506-E running IOS-XE 3.3.0X0(15.1(1)XO). For the most part, this switch was very similar to the older 4500’s. Most of my configuration from the other 4500’s easily pasted into the switch. I was doing well until I got to the QOS portion of the config. I found that with the exception of the Marking policy, nothing else worked.

What did not work?
1. Trust DSCP commands on the uplink ports
2. Egress queueing, mapping COS value to the hardware queue
3. COS To DSCP mapping
4. Selecting the priority queue, what queue was the priority queue?

After some more digging I found out that the 4500 trust DSCP and COS values by default. This explains why the commands would not work. This in itself may cause new challenges to you. If you are not careful, an end user or application could put all of their traffic in the EF queue and use up all of your priority bandwidth. To resolve this challenge, I mark all traffic coming in from an edge port. How do you handle this?

Egress queuing, this is done with a policy map just like a router. The switch comes with 8 hardware queues. (I’m very happy to hear that Cisco finally added 8 hardware queues per port on their switches. Other vendors have been doing this for years.) In your policy map you identify what queue you want to be the priority queue, then under each class you can specify the bandwidth you want to give that queue. For more information on how to configure the policy map, please refer to the Cisco IOS XE Documentation You do need to be careful while going through this guide. The IOS XE software works on routers too. You may find documentation that only applies to ASR routers, but does not work on the 4500 platform.

COS to DSCP mappings may not be needed. I mark all of my traffic at the edge port with DSCP values. I mark DSCP so I do not need to worry about the COS value being dropped going over an access port. With IOS XE, the outbound queuing policy is capable of queuing egress traffic by DSCP value. Due to this, I don’t have to worry about the COS to DSCP or DSCP to COS mappings.

Now for the priority queue and mapping QOS markings to a hardware queue. This has been a major frustration for me due to the different capabilities and commands on the variety of Cisco platforms. To me, this has been no different then if every platform was a different vendors equipment. Due to the challenges in the past, I was really getting upset when I wasn’t able to find any documentation on how to perform this mapping. After speaking with my Cisco SE, I found out that IOS XE will automatically place the different classes in your policy map into different hardware queues. The specific queue for the priority traffic is GONE!!! The unique commands of allocating QOS markings to hardware queue is GONE!!!

Even though this new IOS was frustrating at first, I believe the changes in IOS regarding QOS is a drastic improvement. The old method was more difficult then I feel it should be. As long as you understand Cisco’s MQC logic, the change in Trust and automatic queuing methods, I believe you will find this IOS much better to work with. Do you agree?

Other then Marking and queuing, what other changes have you notices in this new version of software?
Are you happy with the newer IOS XE on the 4500?