Port mirroring concerns on Enterasys S6

[Justin_Brown]

Forgive me if this has been asked before and/or is just a dumb question.

I'm working with a large installation that has been having regular network communication issues. They're using a wireshark-like device to which they've mirrored every port across their backbone, that's about 200 gigabits of throughput being mirrored to a single gig-ethernet port. My concern is what sort of performance impact would such a configuration have. I've been monitoring their interfaces and have yet to see any traffic rise beyond about 300 megabits and that was across 10 gig fiber. My suspicion is traffic is being constrained to fit that gig-e port. I've been watching the mirror source and have yet to see any discarded packets which I would expect to happen constantly given the disparity in bandwidth between the targets being mirrored. In the past I've seen devices wherein port mirroring would block when traffic across interfaces being mirrored reached the limits of the port mirrored to. While I doubt Enterasys behaves similarly unfortunately I know next to nothing about them and haven't been able to find a definitive answer. I suspect this is configuration dependent. Does anyone have a spare moment to school me in the ways of Enterasys port mirroring?

Here are some device details:

Copyright (c) 2013 by Enterasys Networks, Inc.

Slot Model Serial # Versions ------ ---------------- -------------------- ------------------------- 4 SK8008-1224-F8 ************ Hw: 2 Bp: 01.03.02 Fw: 08.11.02.0001 5 SK8008-1224-F8 ************ Hw: 2 Bp: 01.03.02 Fw: 08.11.02.0001 6 ST8206-0848-F8 ************ Hw: 1 Bp: 01.03.02 Fw: 08.11.02.0001 Option Modules: Slot Module Model Serial # Versions ---- ------ ---------------- -------------------- ------------------------- 6 2 SOT2206-0112 ************ Hw: 10

Port mirror config:

set port mirroring create ge.6.40 tg.4.1 both set port mirroring create ge.6.40 tg.4.2 both set port mirroring create ge.6.40 tg.4.3 both set port mirroring create ge.6.40 tg.4.4 both set port mirroring create ge.6.40 tg.4.7 both set port mirroring create ge.6.40 tg.4.8 both set port mirroring create ge.6.40 tg.5.19 both set port mirroring create ge.6.40 tg.5.20 both set port mirroring create ge.6.40 tg.5.21 both set port mirroring create ge.6.40 tg.5.22 both set port mirroring create ge.6.40 tg.5.23 both set port mirroring create ge.6.40 tg.5.24 both set port mirroring create ge.6.40 ge.6.33 both set port mirroring create ge.6.40 ge.6.34 both set port mirroring create ge.6.40 ge.6.35 both set port mirroring create ge.6.40 ge.6.36 both set port mirroring create ge.6.40 ge.6.37 both set port mirroring create ge.6.40 ge.6.38 both set port mirroring create ge.6.45 tg.4.1 both set port mirroring create ge.6.45 tg.5.1 both

Any info/advice is most appreciated, thanks!

[Mike_D]

Hello Justin,

Here is the link to a new knowledge article based on your inquiry.

https://gtacknowledge.extremenetworks.com/articles/Q_A/S-series-K-series-Will-mirror-oversubscriptio...

Thanks again for closing the loop.
Regards,

Mike

[Mike_D]

Thank you for the follow-up Justin. I'm certain this info will be of use to our customers in the future.

I'll create a knowledge base article to the effect that over-subscription of a port mirror does not impact router performance and post the link here.

Regards,
Mike

[Justin_Brown]

I got a definitive answer straight from Extreme. This configuration DOES mirror ge.6.40 to all the other ports. It should not impact router performance as the mirroring is handled by hardware. If this were properly configured (ports being mirrored to ge.6.40 instead of the other way around) when overrun packets intended for the target (ge.6.40) would be discarded. There's currently no method of tracking the discarded packets. Hopefully this will help anyone else with the same concerns.

[Justin_Brown]

I should add unlike other devices, port mirror targets continue to handle other traffic. With other devices when a port is configured to be a mirror target that port only mirrors packets (presumably because passing other packets might confuse packet sniffers). Apparently the S-series behaves differently.