[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

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

[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

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

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

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

Re: [c-nsp] what is it with 3550s?

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

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

[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

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

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

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

[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

[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

[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

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

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

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

[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

[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

[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

[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)

[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

[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

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