2nd Ethernet Port

  • 2
  • Question
  • Updated 4 years ago
  • Answered
What is the purpose of the 2nd Ethernet port of the Zone Director ?
Photo of LoGo

LoGo

  • 2 Posts
  • 0 Reply Likes

Posted 4 years ago

  • 2
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 51 Reply Likes
https://support.ruckuswireless.com/an...

Basically it's to allow for an HA port config with redundant switching (as long as STP is in place)
Photo of Michael Behr

Michael Behr

  • 2 Posts
  • 0 Reply Likes
So, does the Zone Director act as a bridge?
If yes - does it send STP packets?
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 51 Reply Likes
No, it is just a single logical interface that happens to have 2 physical ports so the connected switches would need to ensure that spanning-tree is observed.
Photo of Michael Behr

Michael Behr

  • 2 Posts
  • 0 Reply Likes
Well if ZD forwards packets from one LAN port to another, it's acting as a bridge.

Let's assume both ports are connected to a switch, then the switch will see its own STP BPDU packets. So, it'll block one of the two ports, avoiding a loop.
Am I right?
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 48 Reply Likes
Just make sure the switch does that actually and it's not a datasheet error.
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 51 Reply Likes
It's not forwarding - in a true bridge a broadcast packet coming in on port 1 would egress on port 2. My understanding is that's not what we do - packets coming to the ZD can come in on either port, but they are not re-broadcast. Packets sourced from the ZD exit both ports - so it's more like port replication than anything else.

Purely for simple port redundancy in case of a hardware failure. STP should keep one physical path blocked at all times, but in case of link failure, the other port should unblock and take over. But the STP would all be on the part of the connected switch.
Photo of Com1 NL - Bas Sanders

Com1 NL - Bas Sanders

  • 32 Posts
  • 9 Reply Likes
Hi Keith,

As mentioned in my previous email... are there any plans to implement 802.3ad or make the two interfaces seperately configurable?

In our design we are tunneling all traffic from our AP's to the ZD's. With the two physical ethernet connections acting as one logical connection this means that all traffic is passing through that single logical interface...twice...

Once inside the LWAPP tunnel form AP to ZD.
Second time when it is bridged form the ZD into the VLAN on LAN.

This basically brings down the theoretical throughput of a ZD to an absolute maximum of 500Mbps.

It would be great if it was possible to configure the physical interfaces as outside and inside so tunnels terminate on the outside, and user traffic is passed to the LAN on the inside.

Apart from the increase in performance this also brings additional security possibilities.

Is this something that Ruckus would see to be implemented?
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 51 Reply Likes
I believe our new SCG controllers would avoid this issue, and while they are big beasts and not suitable for everyone may be something to look at in your environment.

I'm not sure the ZD (at least not all of them) could accommodate a change like this at the hardware layer but I will pass the suggestion on to the product manager.
Photo of Com1 NL - Bas Sanders

Com1 NL - Bas Sanders

  • 32 Posts
  • 9 Reply Likes
Hi Keith,

I know the SCG has indeed the functionality needed.. pricetag is still not within range though ;-)

I can imagine the ZD1100's would lack performance needed to cope with this increase, but on the 3K and 5K it shouldn't make a difference. There is however a change in setup needed in redboot to offer the two physical interfaces to the local OS.

The increase in functionality it brings is huge though..

- Split 'inside' and 'outside' interfaces for increased security.
- huge increase in available bandwidth/performance.
- the possibility to bring 802.3ad or similar link bundling.
- possibility to offer an 'out-of-band' management interface.