I am wondering if it's possible to set up a way to remove the need for a bypass switch when using an IPS device. To summarize, I would have an IPS device acting as a virtual wire on a connection I'm monitoring. I also have a bypass switch to do this so that if the IPS fails, the network connection will bypass the IPS device and maintain the connection (I am aware of the security concerns with failing open).

By VLAN bridge, I mean 2 access ports in 2 different vlans that are physically connected. So, my thought was to have the IPS device act as that physical wire between the 2 access ports. In addition, if I had another loop between 2 different access ports with a higher STP cost, I should effectively have a bypass (if IPS went down, STP would take care of the bypass by switching to the other loop). The idea in general works when my loops are between 2 different switches.

However, I had some trouble getting this to work on a single switch. I was testing this with 2 computers in the 2 different vlans pinging each other. So, it's possible I'm just having some ARP problems, and this would work if I can get around that, but I'm not sure yet.

Is this too crazy of an idea to ever work, or am I just missing something?

  • I should add that my theory on why I have problems on a single switch is that the MAC addresses listed for the 2 test computers are listed for the different vlans, but when on 2 switches each switch assumes both computers are on one vlan. I can elaborate further if this doesn't make sense to anyone.
    – Paul Kroon
    May 30, 2013 at 14:38

4 Answers 4


I don't believe this will be possible on one single switch. The reason being is that you are relying on STP to catch a link failure, but to go back to back on a single switch, you would have to suspend normal STP operation by either BPDU filtering or something similar.

  • It should be safe to assume STP would see the loss of BPDUs on this special link because the IPS would no longer be passing them. The idea is that bypass switches work by sending a special frame across on regular intervals, and switches to bypass mode if it ever stops seeing the special frame pass through. The idea should be the same, just with BPDUs in place of the special frame (or at least that's my theory).
    – Paul Kroon
    May 30, 2013 at 16:23
  • 1
    My point is that to connect a switch back to back, the switch would be seeing BPDUs. If you are saying that the IPS will be generating it's own BPDUs and you can mess with them, then it could work. To connect a single switch, back to back, you'd have to basically disable STP bpdus from traversing that link as you are creating a loop that STP is designed to avoid and that most switches will detect and block or disable.
    – Odeonevets
    May 30, 2013 at 16:37
  • Ok, I think I see what you mean. It only worked with 2 switches because of the different bridge IDs. Even though there isn't an actual loop, STP discard the BPDU because it has the local bridge ID. If I disabled STP on that link, I could get it to work, but then I couldn't have a redundant loop for the bypass portion because that would be an actual loop. Does that sound accurate?
    – Paul Kroon
    May 30, 2013 at 17:56
  • That is spot on.
    – Odeonevets
    May 30, 2013 at 18:05

Is there a need for two different VLANs? Depending on the variant of STP you're running, this may actually make things harder.

The other thing to consider with what you're proposing is that you can't guarantee that the IPS failure will drop both the interfaces. If the software crashes for example, but interfaces stay up, spanning-tree may not re-converge correctly.

The real test will be - does your IPS absorb BPDUs, or pass them transparently

  • The general idea is that it does pass BPDUs. When I had this running between 2 switches, I could see the BPDUs pass, and this is why STP was able to detect a software failure and block those ports (and set my backup loop to forward). I would imagine I need 2 different VLANs because I would need traffic to pass from one to the other for the IPS to see it (the idea being internal and external are the 2 vlans, and Internet traffic would be routed between them -- ie, 2 routers in same subnet, but in the different vlans).
    – Paul Kroon
    May 30, 2013 at 14:36
  • Sorry, I missed the bit about you using a single switch. I'd probably try to have an inside and outside switch, IPS in the middle, along with a bypass cable, with the same VLAN on both sides and STP port costs adjusted accordingly. May 30, 2013 at 22:15

It will probably work, but I wouldn't use that kind of solution for production bypassing. The proper to do this (even if not the best practice), is to have bypass built-in your IPS device. Meaning that if device fails it will act as a cable even if there is no power.

Ofcourse you want to have some kind of monitoring on your device to detect outages and respond accordingly.

Hope it helps.


If the IPS is fully transparent (relaying BPDUs, not doing any sort of VLAN mappings by itself), you can use VLAN mapping/translation.

Basically, you define two VLANs, external and internal. The external switchport carries the external VLAN (probably a trunk port), the internal switchport the internal VLAN. At the internal switchport, you configure VLAN mapping/translation. c6500s will take care of translating BPDU information, so you dont get any mismatch errors.

This even works with redundant switches/IPSes, the second installation will have its internal block blocked.

I've done this with 6500 Sup720 and 67xx linecards (which have the limitation of applying the VLAN mapping per port ASIC), cant say if this works with other gear.

Another drawback is that you have to deal with different VLAN IDs for external (upstream) and internal (downstream) devices, which could impact planning and troubleshooting.

  • Can I assume the VLAN translation you're referring to is a feature of the c6500s (switchport vlan mapping enable)? I was hoping to stick with just trunk/access ports and standard STP functionality because this would likely be on Dell PowerConnect 5548s. Since this is a feature of the 6500s, it at least seems that I'm not too off-base in trying to mimic this functionality.
    – Paul Kroon
    May 30, 2013 at 17:45
  • Yes. I think there are only few other cisco switches (metro and 4500 series) that do support vlan translation.
    – mmi
    May 30, 2013 at 18:04
  • More specifically, the translation was required to make the 6500 accept its own RPVST+ BPDUs (from a different port/vlan). Basically, the IPS is just a back to back cable you attach between two switch ports. You dont even need STP if you run a single IPS box only. If you can make a redundant setup work with Dell switches, with a working STP in both VLANs, then you do not need VLAN translation. Working means that when using two IPS boxes, one of the four interfaces is blocking.
    – mmi
    May 30, 2013 at 18:25
  • Yes, that was my intention, although it seems that I need that feature because of the answer from Odeonevets (accepting its own BPDUs). My thought was to just use a single cable rather than a second IPS device, but the idea would have been the same.
    – Paul Kroon
    May 30, 2013 at 18:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.