Switching

I have 4 EX 4550's setup in a VC, two per site.

At each site I have an IPS but they don't have the smarts to do their own fail-over. The EX is doing VLAN translation to force frames for "clean" and "dirty" VLANs through the IPS but if I do this at both sites it'll cause a loop.

What I really would like to do is have the sets of IPS interfaces connected to reth interfaces on the EX VC. Such that both IPS' "clean" interfaces were linked, and both "dirty" interfaces were linked. I would have them in the same reunddanct group so that if say the active clean interface died it would fail both active links over to the other reth member.

Hopefully I've explained that correctly. But I can't see any mention of reth feature for EX.

Hello,

Please use LAG with link-protection

http://www.juniper.net/techpubs/en_US/junos12.3/topics/task/configuration/802-3ad-link-protection-multi.html

HTH

Thanks

Alex

---

@aarseniev wrote:

Hello,

Please use LAG with link-protection

http://www.juniper.net/techpubs/en_US/junos12.3/topics/task/configuration/802-3ad-link-protection-multi.html

HTH

Thanks

Alex

---

Hi, thanks for the info but unfortunately that won't help: Since the interfaces to the IPS are in pairs, any failure of one interface needs to be acted on both interfaces rather than just one.

I.e. we have an A and a B interface on each IPS. Call them 1A, 1B for the primary IPS and 2A, 2B for the secondary.

1A and 2A are put in link protection state. This will be good to start with as it'll ensure both aren't enabled at once and prevent loops. 1B and 2B can probably just remain up as it won't cause any issues without the other interface being up.

If 1A fails then we're covered - 2A will take over, and traffic will flow through the secondary IPS since 2B is also up.

However if 1B fails we have no mechanism to act on to force the A ports to change over. 1B fails but 1A  will stay up thus preventing any traffic from traversing either IPS.

Hello,

---

@bfranklin wrote:

---

 

I.e. we have an A and a B interface on each IPS. Call them 1A, 1B for the primary IPS and 2A, 2B for the secondary.

 

1A and 2A are put in link protection state. This will be good to start with as it'll ensure both aren't enabled at once and prevent loops. 1B and 2B can probably just remain up as it won't cause any issues without the other interface being up.

 

If 1A fails then we're covered - 2A will take over, and traffic will flow through the secondary IPS since 2B is also up.

 

However if 1B fails we have no mechanism to act on to force the A ports to change over. 1B fails but 1A  will stay up thus preventing any traffic from traversing either IPS.

 

 

 

---

Does IPS support 802.1Q trunking? Does IPS support LAG?

If yes to both then rather than using 1 IPS interface as ingress  and 2nd interface as egress, You can aggregate both IPS interfaces into a LAG and configure 2 VLANs across this LAG: 1 VLAN for ingress and 2nd for egress.

Then, if 1 interface fails, IPS will be still functional with reduced BW, of course. If 2 interfaces fail, You can reroute traffic to 2nd IPS.

No special protection is necessary in this case.

HTH

Thanks

Alex

---

@aarseniev wrote:

Hello

Does IPS support 802.1Q trunking? Does IPS support LAG?

If yes to both then rather than using 1 IPS interface as ingress  and 2nd interface as egress, You can aggregate both IPS interfaces into a LAG and configure 2 VLANs across this LAG: 1 VLAN for ingress and 2nd for egress.

Then, if 1 interface fails, IPS will be still functional with reduced BW, of course. If 2 interfaces fail, You can reroute traffic to 2nd IPS.

No special protection is necessary in this case.

HTH

Thanks

Alex

---

Hi Alex - thanks again for the reply.

Unfortunately that isn't possible either due to the way the IPS's work (remember there's 2 as well). The IPS has sets of interface pairs and you have to have traffic ingress via one and egress via the other. It's bi-directional but has to pass through the pairs. They have close-open failure kits that can become a physical pass-through in the event of the IPS dying, and the IPS actually is invisible to layer 2 and beyond. 

The extra complication comes from the way we connect the IPS ingress and egress to the same switch and use VLAN translation to create a bridge via the IPS. We used to do this on a 6509 but had a lot of issues with bpdu's given we were effectively looping back on the switch (since the IPS is invisible).

Hello there,

---

@bfranklin wrote:

 

Unfortunately that isn't possible either due to the way the IPS's work (remember there's 2 as well). The IPS has sets of interface pairs and you have to have traffic ingress via one and egress via the other. It's bi-directional but has to pass through the pairs. They have close-open failure kits that can become a physical pass-through in the event of the IPS dying, and the IPS actually is invisible to layer 2 and beyond. 

 

The extra complication comes from the way we connect the IPS ingress and egress to the same switch and use VLAN translation to create a bridge via the IPS. We used to do this on a 6509 but had a lot of issues with bpdu's given we were effectively looping back on the switch (since the IPS is invisible).

---

Okay, then does IPS pass through the LACP PDU?

If yes then You can enable LACP on EX interfaces connected to IPSes and have a EX 1-member LAG "looped" via one IPS, and 2nd EX 1-member LAG "looped" via 2nd IPS.

LACP PDU will serve as sort of "probes" through IPS, and once IPS stops passing them through, then corresponding AE interfaces on EX will go down, triggering failover to 2nd IPS.

HTH

Thanks

Alex 

That's brilliant. I'll see if I can get it tested in the lab. We had someone workong on a script to watch port status and shut down/activate ports depending, but this is much cleaner.

Got it working with LACP + added Link Protection since it was a requirement that only one IPS at a time was the designated active sensor.

With non-revetive link protection I can ensure that in the event of a link failure it'll swap to the standby unit and stay there until the config is switched back to "revertive" temporarily in order to swap to the initial unit.