[f-nsp] sflow through management interface
Wilbur Smith
wsmith at brocade.com
Thu May 21 14:47:08 EDT 2015
Hi Rodney,
Unfortunately, the MLX doesn’t support forwarding sFlow traffic out its management port; this limitation has to do with how the Management Module works. These ports are closer to a server’s iLO port than an actual Ethernet port.
On the MLX, the MM doesn’t actually connect to the router’s data-plane fabric. Each line card runs a copy IronWare locally, so they behave like individual routers for each card (this is what each LP has its own CPU, RAM, and Flash in addition to the Traffic Manager and Packet Processor chips). The Management Module’s job is to make sure table data stays in sync across all the cards, but its really not making the forwarding decisions for each LP.
The MM talks to each LP through a separate internal network that only connects to the CPU in each LP; this is called the IPC Buss. Since the connections between the MM and LPs aren’t part of the data-plane inside the box, there’s no way to get the sFlow data to the Management Module’s Ethernet port. Even if we could do this, we wouldn’t want to…too much sFlow traffic could overwhelm the IPC Buss and lock up the router.
Although this architecture is a bit limiting for sFlow, it’s what allows someone to SSH into the MLX even if there’s a L2 loop or heavy load. It’s also why the MLX can run at 100% capacity on the backplane and still have the CPUs run at 1%.
If your router is out of ports, I’d see if you can create a seprate management vlan to move sFlow data through. You can sonfigure sFlow to only forward traffic out of a specific VE, so this would give you a way to keep the sFlow data away from existing traffic.
Wilbur
From: foundry-nsp [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of i3D.net - Martijn Schmidt
Sent: Thursday, May 21, 2015 12:16 PM
To: foundry-nsp at puck.nether.net; tech at elecks.nl; i3D.net - Martijn Schmidt
Subject: Re: [f-nsp] sflow through management interface
Hi Rodney,
Is there any special reason why you can't just send the sFlow samples to
your collector server as in-line traffic? You don't need a dedicated
interface for sFlow, it's not port mirroring. :-)
Best regards,
Martijn
On 05/21/2015 08:07 PM, tech at elecks.nl<mailto:elecks.nl> wrote:
> Hi,
>
> We use a NI-XMR-MR with NI-XMR-10GX4.
> Has it pro/cons to run sFlow through the management interface (slow
> down?) ?
>
> We setting up sFLOW but we have no ports free only the mangement
> interface from the XMR-MR card.
>
> Regards,
>
> Rodney
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net<mailto:puck.nether.net>
> http://puck.nether.net/mailman/listinfo/foundry-nsp
Best regards,
Martijn Schmidt
http://www.i3D.net
[cid:image002.jpg at 01D093C1.DB8B1200]i3D.net is a private company registered in The Netherlands at Meent 93b, Rotterdam. Registration #: 14074337 - VAT # NL 8202.63.886.B01. i3D.net is CDSA certified on Content Protection and Security and provides hosting from 16 global ISO-certified datacenters. We are ranked in the Deloitte Technology Fast 500 EMEA as one of the fastest growing technology companies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20150521/a14a15a5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 15170 bytes
Desc: image001.jpg
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20150521/a14a15a5/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 2599 bytes
Desc: image002.jpg
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20150521/a14a15a5/attachment-0003.jpg>
More information about the foundry-nsp
mailing list