[80625] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

RE: Two questions [controlling broadcast storms & netflow software]; seeking offlist responses

daemon@ATHENA.MIT.EDU (Peter Kranz)
Thu May 5 16:33:05 2005

From: "Peter Kranz" <pkranz@unwiredltd.com>
To: "'Drew Weaver'" <drew.weaver@thenap.com>, <nanog@merit.edu>
Date: Thu, 5 May 2005 13:32:21 -0700
In-Reply-To: <B9ECBF8D89E7684EB63FF250E8788B1911938B@BIGLOG.thenap.com>
Errors-To: owner-nanog@merit.edu


The approach we have used in our network has worked well for this =
deployment
scenario.. Here is our approach

1) Each customer is configured as a sub interface on the GSR with an
individual VLAN tag per customer
2) The GSR talks to the BD 6808 using GigE ports, all the VLAN tags are
carried on the GigE ports
3) The BD6808 received the tagged traffic on the GigE port and routes it =
to
=91untagged=92 customer facing ports via 1 VLAN per customer. That VLAN =
is a
member of the GigE port 'tagged' and the customer port 'untagged'.

In this manner, every customer is isolated into its own VLAN, and the =
GSR
handles routing between the VLANs

In this configuration, we have not had any broadcast storm issues..

Peter Kranz
Founder/CEO - Unwired Ltd
Mobile: 510-207-0000
pkranz@unwiredltd.com
________________________________________
From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of =
Drew
Weaver
Sent: Thursday, May 05, 2005 1:27 PM
To: nanog@merit.edu
Subject: Two questions [controlling broadcast storms & netflow =
software];
seeking offlist responses

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Hi. We=92ve been using the same =
topology for our Fast Ethernet
network for awhile, it has grown quite a bit lately and we=92ve wanted =
to
change it around. We=92ve been running into some problems with =
broadcasts
traversing vlan boundaries and we=92ve become a tad stumped by this.. =
Here is
an example of what we=92re doing with the network.

We=92re using Black Diamond 6808 switches by extreme, those switches are
connected to Cisco GSR 12000 routers which then connect to the Internet

On the extremes every server is connected to its own vlan, and the =
upstream
connection to the router Is in its own vlan. The extreme is doing layer3 =
(so
all of the IP addresses are routed to the switch)=20

So the VLAN would look something like this..

192.168.0.0/29 The Server=92s IP would be 192.168.0.2 The Black =
Diamond=92s IP
would be 192.168.0.1 So the server=92s gateway would be .1

We have IP forwarding enabled on all of the VLANs so that the traffic =
can go
from the SERVER=92s VLAN to the UPSTREAM=92s VLAN.=20

I realize that there are certain design flaws inherit here, can someone
point out a better way to design this, if you have any questions I would =
be
happy to answer them.

Also all of the vlans are untagged in the black diamond, and there is no
vlan configuration for them whatsoever in the GSR 12000. =A0

The basic problem is that once in a blue moon we get problems where
something will eat up a great deal of cpu cycles in the switch and its
almost always a broadcast storm. (which is supposed to be eliminated by
private VLANs.

One idea I had was to use the black diamond as a layer2 switch and then =
use
the GSR to do the routing, but that seems kind of round-about.

Any other ideas?

Also the other question I had was are there any very good either open =
source
or fairly affordable netflow analyzer software packages out there right =
now?

Thanks,
Andrew





home help back first fref pref prev next nref lref last post