Two questions [controlling broadcast storms & netflow software]; seeking offlist responses
Hi. We've been using the same topology for our Fast Ethernet network for awhile, it has grown quite a bit lately and we've wanted to change it around. We've been running into some problems with broadcasts traversing vlan boundaries and we've become a tad stumped by this.. Here is an example of what we're doing with the network. We're 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) So the VLAN would look something like this.. 192.168.0.0/29 The Server's IP would be 192.168.0.2 The Black Diamond's IP would be 192.168.0.1 So the server's gateway would be .1 We have IP forwarding enabled on all of the VLANs so that the traffic can go from the SERVER's VLAN to the UPSTREAM's VLAN. 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. 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
Hi Drew,
-----Original Message----- <SNIP> 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.
Why does this seem round-about? Depending on the line cards and IOS revision you are running in that GSR it could be a really good solution. Black Diamonds in general are not a favorite in the network community right now (re PAIX) but turning into a layer2 only device probably will get you the performance/stability that you need at least until you max-out that layer of your network. It seems like your design is very much a vanilla hosting setup, using small blocks of IP's and isolating each server on its own vlan are great practices. You will find it rather easy to migrate to the above setup because of the way you have done things. Again make sure the line cards and IOS that you use can support the # of vlans and ARP entries that you currently support in your BD setup. _Scott
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 untagged 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 Hi. Weve been using the same topology for our Fast Ethernet network for awhile, it has grown quite a bit lately and weve wanted to change it around. Weve been running into some problems with broadcasts traversing vlan boundaries and weve become a tad stumped by this.. Here is an example of what were doing with the network. Were 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) So the VLAN would look something like this.. 192.168.0.0/29 The Servers IP would be 192.168.0.2 The Black Diamonds IP would be 192.168.0.1 So the servers gateway would be .1 We have IP forwarding enabled on all of the VLANs so that the traffic can go from the SERVERs VLAN to the UPSTREAMs VLAN. 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. 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
Drew Weaver writes:
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?
Making a recommendation is difficult, because there is such a wide variety of requirements, depending on context (backbone/campus/ hosting) and application (billing/security/traffic planning). But I try to keep a comprehensive list of Netflow-related software on http://www.switch.ch/tf-tant/floma/software.html#netflow Hope this helps, -- Simon.
participants (4)
-
Drew Weaver -
K. Scott Bethke -
Peter Kranz -
Simon Leinen