[c-nsp] NetFlow for billing on 6500/SUP720-3B
Hi all, A bit of background... We are preparing to deploy our first pair of 6509s with a SUP720-3B supervisors and WS-X6548-GE-TX line cards (we may also have a few WS-X6748-GE-TX cards as well). These will be used for core/customer distribution primarily, with a pair of Juniper M7i routers at the edge. These switches are used in a Data Center / Co-lo type environment and are replacing a bunch of aging Cisco 3550s. My question... We have traditionally used mirror ports in a L2 switch attached to a FreeBSD box with NICs in promisc. mode to do our traffic accounting (monitoring the traffic to/from the edge and ignoring local traffic). However, with the new 6509 platform, we are hoping to use NetFlow v9 instead and get rid of the sniffer box. Our hope is that we can monitor each customer port (which is configured as a L3/routed port) and export only the flows to/from the edge to our collector, and then use that data for billing purposes. My concern is that, due to our inexperience with the 6500 platform, I want to make sure we don't run into any performance issues or, worse yet, stability issues in IOS. Any advice along these lines would be appreciated. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3560G-E's as replacement for 3550-EMIs for dist switches?
Are you relying on QoS in the 3550? If so, you'll be disappointed with the 3560/3750. Nope, no QoS. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] 802.3ad questions..
Hi all, We have (2) Metro Ethernet connections from two different carriers connecting our two locations at the moment. We need to provide for redundancy at the L2 level for these, and would like to combine the bandwidth into one logical bundle. I'm fairly well versed at the L3 level, but have little experience of L2 features (aside from VLANs), so I was looking for a bit of guidance. We will be using Cisco switches on both sides of the link(s), and it seems 802.3ad is the way to go -- but I'm not sure if LACP or EtherChannel is appropriate here, or if there is something else I should be considering. Also, to throw another issue into the mix -- these two links are not currently equally sized -- one is shaped to 600M, the other is a full Gig, so a way to specify link speed and have it load balanced appropriately would be great as well. TIA. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PVLANs in a Hosting Environment
Matt, We looked at doing this ourselves a few years back. We decided to push L2 responsibility down to the customer rack and do all L3 at the distribution layer. We use the venerable WS-C3550-48-EMI switches for this duty, and they have been rock solid for years. We did have a few customers complain at first that they were now required to buy a switch whereas we provided L2 beforehand, but this was a minority of customers and it has since turned out to be a great decision. We are now looking at our upgrade path from the 3550's to the next generation that supports IPv6 and all Gigabit ports, etc.. (looking at the 3750G's, Juniper EX series, and Foundry FESX-PREMs) Matthew Melbourne wrote: Hi, We are investigating options to provide a VLAN-per-customer within a hosting environment. Inside each VLAN could be hosting services, e.g. hosted web servers, AD, Exchange (etc). In order to maximum the number of supported VLANs, then the use of Private VLANs has been raised. However, although L2 isolation is desirable between customers (effectively a PVLAN community), there may be a requirement to communicate at L3 (e.g. one customer accessing the web site of another). A classical VLAN per customer would utilise more address space than a PVLAN and would require an SVI per customer. What do others do in this type of environment? We would want to offer additional services going forward, e.g. firewalling/load-balancing which may have implications for PVLAN awareness. A number of services may well be hosted within a virtual environment, and it is my understanding that all devices need to support PVLANs including virtual switches within any VMware/HyperV-like server environment? Cheers, Matt -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] what is it with 3550s?
We currently aren't doing any QoS, and a limited amount of policing. Besides the C3750G, are there any other switches worth a look? We're a mixed Juniper/Cisco shop, so I've been looking at the EX3200 line as well. We need something that will do OSPF and limited BGP (just to announce customer subnets back in to the network). sth...@nethelp.no wrote: We've got a boatload of 3550-EMI's (for colo/server aggregation duties) and are looking at replacing them in the next 12-24 months The C3750G-24/48-E series seem to be a good upgrade path (all gig ports, layer3 routing, IPv6 support, fairly easy to source on the used market) -- curious as to why you said they didn't look viable... I'd say it depends a lot on how you use your 3550s. One point which is significantly different on 3560/3750 is QoS/policing. Steinar Haug, Nethelp consulting, sth...@nethelp.no -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] what is it with 3550s?
The 3560G's w/ipservices (-E) seem to be more expensive than the corresponding 3750G counterparts for some reason, so we've been primarily looking at those. Tony Varriale wrote: - Original Message - From: TCIS List Acct lista...@tulsaconnect.com To: sth...@nethelp.no Cc: cisco-nsp@puck.nether.net; jle...@lewis.org Sent: Sunday, February 21, 2010 3:00 PM Subject: Re: [c-nsp] what is it with 3550s? We currently aren't doing any QoS, and a limited amount of policing. Besides the C3750G, are there any other switches worth a look? We're a mixed Juniper/Cisco shop, so I've been looking at the EX3200 line as well. We need something that will do OSPF and limited BGP (just to announce customer subnets back in to the network). If you aren't going to use Stackwise look at the 3560s. In the J lineup, the EX4200s should suit you well. tv ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] what is it with 3550s?
Also, we've been looking more towards the Cisco's because the Juniper EX series seem to require a feature license for even basic BGP on the 2200/3200 series. Our BGP needs are quite modest (just announcing customer subnets back into the network), and this priced them out of the budget.. Tony Varriale wrote: - Original Message - From: TCIS List Acct lista...@tulsaconnect.com To: sth...@nethelp.no Cc: cisco-nsp@puck.nether.net; jle...@lewis.org Sent: Sunday, February 21, 2010 3:00 PM Subject: Re: [c-nsp] what is it with 3550s? We currently aren't doing any QoS, and a limited amount of policing. Besides the C3750G, are there any other switches worth a look? We're a mixed Juniper/Cisco shop, so I've been looking at the EX3200 line as well. We need something that will do OSPF and limited BGP (just to announce customer subnets back in to the network). If you aren't going to use Stackwise look at the 3560s. In the J lineup, the EX4200s should suit you well. tv ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- - Mike Bacher / lista...@tulsaconnect.com TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco RPS for 3550 switch
Terje Bless wrote: On the RPS-300, we didn't do the checking we should have before buying and ended up with what for us were essentially 30 boat anchors. My conclusion in the end was that it's much better to keep (in our case) a bunch of spare 3524s (another brilliant purchase, *sigh*) and replace the entire unit in case of PSU (or other) failure. The RPS-300 and its ilk simply makes zero sense to me (even if it's now dirt cheap). Oh, we have plenty of spare 3550's and would swap the entire switch in case of a internal PSU failure, it is just a matter of wanting to control downtime vs. having an outage in the middle of the night. The RPS-300 seems to provide at least that much benefit. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Cisco RPS for 3550 switch
We are looking at options to provide redundancy for the internal A/C power supply in some 3550-48-EMIs. It seems that the following RPS models will work: RPS-300 RPS-675 RPS-2300 We plan to do a 1-1 config (1 RPS for 1 switch), so we are leaning towards the RPS-300 for cost reasons. I've reviewed various threads in the archive, and see where others have had problems with the RPS-300's allowing fall-back to the internal A/C power supply after it has taken over on the DC source. Was this an IOS issue, a hardware issue with the switch and/or RPS, or ? Also, I keep seeing this warning in the docs: The Catalyst 3550 switch and the Cisco RPS 300 or RPS 675 should be connected to the same AC power source. We had planned to power the internal source from one PDU, and the RPS from another PDU (both PDUs are fed by the same UPS source, but we wanted to guard against a PDU failure). What is the real issue here -- and am I asking for trouble by ignoring this warning? TIA. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco RPS for 3550 switch
Daniel Suchy wrote: Hello, On 10/01/2007 06:07 PM, TCIS List Acct wrote: I've reviewed various threads in the archive, and see where others have had problems with the RPS-300's allowing fall-back to the internal A/C power supply after it has taken over on the DC source. Was this an IOS issue, a hardware issue with the switch and/or RPS, or ? It's a switch/hardware issue. Understood. I found a Cisco bug on this issue, that basically says some switches may reboot upon transfer back to internal power, some may not, do at your own risk. Also, I keep seeing this warning in the docs: The Catalyst 3550 switch and the Cisco RPS 300 or RPS 675 should be connected to the same AC power source. I had never problems with this - I always used RPS for redundancy (using splitted power feeds). Good to hear. I couldn't understand the logic behind the same AC power source statement, unless it was just protecting Cisco from having to deal with the issue above (not failing back to the internal P/S once the RPS has taken over), which would be more likely in a scenario where the RPS and internal P/S were on different feeds. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco RPS for 3550 switch
Seth Mattinen wrote: Hardware. There is no way to get the device (in my case, some 2811's on a single RPS-300) to go back to internal power without reloading once it's switched over to the RPS. Switching back causes the device to lose power. You should not expect any kind of real redundancy, but expect a full outage and reload if you ever want to go back to internal AC from the RPS. Personally, I'd just skip the one to one redundancy and just use them for nothing more than protecting the switch from internal PSU failure, at which point you'll have to power it down anyway to replace the PSU. This doesn't affect any other devices plugged into the RPS, only the one actually drawing power from it. ~Seth The RPS-300 is dirt cheap these days (~$50 or less), so 1-1 isn't a big deal for this project. I did see somewhere on the archives that someone said pulling the AC power from the RPS (vs using the active/standby buttons) will allow the switch to fail back to its internal P/S without a reboot. I'll try this when I get our first RPS-300 in and see how it goes. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco RPS for 3550 switch
Seth Mattinen wrote: I've tried it; doesn't work on my gear. I'd always plan for full outage though if you ever have to switch back to internal power. The RPS-600 was so much better than what's being passed off as a redundant power supply these days... I never bothered using the AC input on the device when it was hooked up to a RPS-600 since it had dual AC and you could use the dual-head RPS cable to give it redundant DC feeds. Truly a redundant power solution for the rest of us. (Totally ignoring the 2948G-L3, of course.) ~Seth Interesting.. does the RPS-600 work with 3550 switches? I'm thinking not, since it just says 3500 series XL on the supported switches matrix.. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Cisco 3550 traffic policing/QoS limitations?
According to: http://www.cisco.com/warp/public/473/153-2.gif It appears that there are limitations on the number of policers that you can use. What isn't clear is how these apply -- in a nutshell, what we want to be able to do is define a policer that limits ingress/egress traffic to 10M (we will likely use ACLs on Ingress to only apply this limit to traffic bound for non-local subnets) on _every_ FE port on our 3550-EMI's. Is this possible or no? TIA. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Cisco 3550 policing limitations?
According to: http://www.cisco.com/warp/public/473/153-2.gif It appears that there are limitations on the number of policers that you can use. What isn't clear is how these apply -- in a nutshell, what we want to be able to do is define a policer that limits ingress/egress traffic to 10M (we will likely use ACLs on Ingress to only apply this limit to traffic bound for non-local subnets) on _every_ FE port on our 3550-EMI's. Is this possible or no? TIA. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Solid L2 switch - 2948G or 3548-XL-EN?
We are looking for a cheap, but solid L2 48-port switch. My investigations have led me to the WS-C2948G and the WS-C3548-XL-EN. I know the 2948G is CatOS based, and the 3548 is IOS based (and both are EOL'ed). Any experiences with these switches in a light-duty environment would be appreciated. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] WS-C3560G-48TS-S per port ACLs?
Tom Zingale (tomz) wrote: Yes on a vlan or port you can allow/deny tcp/ip traffic. See the docs http://www.cisco.com/en/US/partner/products/hw/switches/ps5528/products_ configuration_guide_chapter09186a008081da63.html Does this same feature (per port IP ACLs on a L2 interface) work on the 2960G line as well? The command reference seems to say it does, but it is unclear if it happens in hardware or software on that platform. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] WS-C3560G-48TS-S per port ACLs?
Tom Zingale (tomz) wrote: Yes the SMI software feature set supports ACL's on a per port basis So I can apply an ACL on a Layer2 port, that allows/denies TCP/IP traffic? I know I can do this on some Foundry switches, but have never tried on a 35xx when the port is not a L3 port.. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] WS-C3560G-48TS-S per port ACLs?
Tom Zingale (tomz) wrote: Yes on a vlan or port you can allow/deny tcp/ip traffic. See the docs http://www.cisco.com/en/US/partner/products/hw/switches/ps5528/products_ configuration_guide_chapter09186a008081da63.html Thanks, that link answers most of my questions. Performance wise, it looks like most of the ACL processing is done in hardware, which is good. We are primarily looking to provide basic firewalling of connected devices, and have no need for NAT or anything other than permit/deny rules. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Catalyst 2960G Experiences
We are looking to pick up a good 24/48 port Gigabit switch for some basic L2 aggregation duties. The main criteria are wire rate performance and rock solid stability. Would appreciate to hear from anyone using the WS-C2960G-24TC-L or WS-C2960G-48TC-L for this purpose. TIA. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Rackmount kit for ASA 5505?
We're considering using ASA 5505's as a replacement for PIX 501's for customers in our DC. I note on this page: http://www.cisco.com/en/US/products/ps6120/products_data_sheet0900aecd802930c5.html Rack-mountable Yes, with rack-mount kit (available in the future) Does anyone know if this kit is available yet? The form factor of the unit and giant power brick with non-standard cord are certainly turn-offs, but the unit does have a nice price point (~$375) TIA. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Stable NPE-G2 IOS for SP?
We've decided to go with multiple 7206VXR/NPE-G2's for our edge routing (replacing older NPE-300/400 devices). We have simple needs -- BGP, OSPF, NetFlow, and some small ACLs on the WAN interfaces. Since the IOS selection for the G2 is somewhat limited, if others can share what IOS release has been stable for them, it would be appreciated. TIA. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] NPE-G2 stability for edge/border routing
Hi all, We're (still) evaluating our options to replace our edge/border routing platform with something with more growth capacity. Currently, we have (2) 7206VXR/NPE400's (one at each of our Data Centers) and terminate (2) DS-3's in one, (1) DS-3 in the other, soon to be (1) DS-3 and (1) OC-3, and (1) DS-3 and (1) GigE Copper (100M commit to start). In any case, we're looking hard at a couple of different options: - Cisco 7206VXR/NPE-G2 - Cisco 6509 w/Sup2/MSFC2/PFC2 and w/FlexWan (we don't need full tables at present, and by the time we do, we can likely afford a Sup720/3BXL. My only concern here is the performance of the FlexWan (non enhanced) taking a full OC-3) - Juniper M7i We are doing BGP, OSPF, and have a few small (50 entries) ACLs on the WAN interfaces, and have a GRE tunnel for some inter-DC redundancy. We are leaning towards the NPE-G2 route, as it will allow us to re-use some of our existing PA's and we are familiar with the 7200 platform already. However, I am concerned with the maturity of the G2. If anyone is using this at their edge/border using a similar feature-set, I would be interested to hear your experience with the G2 with regards to stability. TIA. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] CoPP on 3550-EMIs
Is the CoPP feature available on the 3550-48-EMI or 3550-12T platforms? If so, what IOS release would I need, and is it hardware or software based? We've got 48-EMI's deployed to our Co-lo network (all L3 interfaces to the customer) and are looking to add some reasonable DoS protection internally. TIA. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] NetFlow for Bandwidth Billing
We are a Co-lo provider looking to improve how we do usage-based bandwidth billing on a per IP/subnet basis. We can't do SNMP monitoring per-port (we exclude local LAN traffic, traffic between our two Data Centers, etc), so we are considering doing bandwidth billing via NetFlow from our 72xx core routers. What are the pros/cons of using NetFlow for usage-based billing? I've seen some discussion regarding NetFlow's accuracy/completeness, so any advice would be appreciated. TIA. -- - Mike Bacher / [EMAIL PROTECTED] TCIS - TulsaConnect Internet Services http://www.tulsaconnect.com - ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] NetFlow for Bandwidth Billing
Bill Nash wrote: Scope and scale are the two big factors when dealing with netflow accounting. You will need full IP address accounting for your customers, ie knowing which customers have been issued which address space. Got that part covered. You will need an understanding of how many flows per second a given customer generates. Not sure on that one. In general, we aren't pushing much more than 80,000pps out our transit links at any given time, and traffic on the Ethernet side is still under gigabit speeds most of the time (excluding backup traffic). What specific metrics do I need to consider regarding flows? I know there are flow expiry knobs, etc in the config.. You will need to determine how and where it's possible to aggregate flows together, based on the level of detail you need. This can be done at the router level[1] or at the analyzer level[2]. Router sourced flow aggregation may not work in a colocation environment if you're issuing single ip's to different customers in the same subnet. Others may have more expertise in this area than I. I couldn't figure out a good way to do it, and it was easier (for me) to do on the analyzer side. Since we only care about accounting for bandwidth that passes in/out of our borders, we planned to do NetFlow on our Cisco 7206VXR/NPE400 (soon to be -G1 or -G2, or 6509 with Sup720/3BXL) core routers. We have some legacy customers on /32's on the same /24, but most are on their own small subnets. [1] Depending on scale and architecture, this may not be healthy for your router. [2] Depending on flow volume and analyzer design, this may require some CPU horsepower. We can throw whatever sized hardware is needed on the NetFlow Analyzer side of things. As for completeness, I've not run into many cases where the flow volume wasn't accurate. The netflow capable platform I worked with was c6509 (as recently as last year), rocking a Perl analyzer that tossed about ~18k flows a minute through Mysql, to the tune of about 400 million flows per day, including LAN chatter, on about 8 gigs of egress capacity. We are nowhere near that on egress capacity, maybe 200-300Mbit at present. There is no netflow solution that's perfect for every network, so you'll want to do some legwork. Despite my experience, I can't personally recommend any particular toolset, since I've always rolled my own. (No, I don't currently have a flow analyzer that I can release.) Our main concern is bytes in/out for billing purposes. Nothing fancy, but we will be sending NetFlow streams from 3-4 different core routers which the NetFlow Analyzer must aggregate and consolidate into a single report per-IP or per-subnet, depending on the customer. --Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
