Re: [c-nsp] IOS 15.0 - why the numbering jump?
On Monday 05 October 2009 10:20:13 am Matthew Marlowe wrote: Peter, Someone on twitter said that Asian culture has a phobia of the number 14,... off-topic Well, to be exact, the Chinese are generally superstitious of the number 4. That includes anything that has a 4 in it, e.g., 14, 24, 34, 44, e.t.c. Conversely, 8 is considered to be associated with good luck and fortune. I can't speak to other Asian nationals/cultures re: numbers. /off-topic similar to the western phobia of 13. I would have preferred Cisco just ignore this stuff, but if they were going to bump, I guess 15 is just as good as 14. At least they are not naming it Cisco IOS 2010 or some such. more off-topic Perhaps Cisco saw Juniper were gaining on them with their upcoming release of JUNOS 10. Knowing Juniper's release cycle, it wouldn't be long before JUNOS 12 became available (oh my, imagine JUNOS 12.2, JUNOS 12.3, JUNOS 12.4, JUNOS 12.5, e.t.c.). I guess IOS 15 keeps Cisco a couple of steps ahead :-). /more off-topic Mark. signature.asc Description: This is a digitally signed message part. ___ 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] IOS 15.0 - why the numbering jump?
Hi, Conversely, 8 is considered to be associated with good luck and fortune. ...and whilst we dont have such superstitions in the Western world life might be better if we did.. ASA 8.x, RedHat 8.x, IE 8.x, SUSE 8.x and IOS 12.2-SXF8 all spring to mind ;-) alan ___ 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] IOS 15.0 - why the numbering jump?
On Monday 05 October 2009 05:09:59 pm Alan Buxey wrote: ... SUSE 8.x... SuSE 8.2 was actually very good - it's been downhill ever since, although I'm still a loyal follower :-). Okay, really going off-topic now :-). Cheers, Mark = who's running openSuSE-11.1 over VMware Fusion 2.0.5 over Mac OS X 10.6.1 signature.asc Description: This is a digitally signed message part. ___ 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] SUP720 - 12.2(18)SXF17
Hi, But yes, splurging a 30gig hard-disk image out over multicast with TTL=1 on the packets will definitely cause TTL-exceeded problems ;o) bonus points++ for the application using a global multicast address too. nice. alan ___ 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] SUP720 - 12.2(18)SXF17
Hi, Not to fault Cisco, or anyone else for that matter but shouldn't switches that cost a quarter of a million dollars be able to protect themselves from these sorts of things just as a default? turn off multicast for that VLAN - its its TTL=1 then it didnt really want to multicast anyway - thats a broadcast :-) alan ___ 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] SUP720 - 12.2(18)SXF17
Alan Buxey wrote: Hi, Not to fault Cisco, or anyone else for that matter but shouldn't switches that cost a quarter of a million dollars be able to protect themselves from these sorts of things just as a default? turn off multicast for that VLAN - its its TTL=1 then it didnt really want to multicast anyway - thats a broadcast :-) alan Alternatively, we do this: interface Vlan55 vrf forwarding xxx ip verify unicast source reachable-via rx no ip proxy-arp ip flow ingress ip pim sparse-mode ip multicast boundary MULTICAST-in ip igmp access-group MULTICAST-in ip access-list standard MULTICAST-in deny 224.0.1.60 deny 224.77.0.0 0.0.255.255 deny 226.77.0.0 0.0.255.255 permit 239.192.0.0 0.3.255.255 deny 239.0.0.0 0.255.255.255 permit 224.0.0.0 15.255.255.255 mls rate-limit all ttl-failure 100 10 mls rate-limit all mtu-failure 100 10 There's no reason not to have the TTL failure rate limit enabled AFAIK. Choose a value appropriate to you, obviously. ___ 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] Monitoring HTTP / url access @10gig
We currently monitor web access from our campus with a VACL capture, picked up by a server-class machine with a 10gig port. Hardware is sup720, and our internet links are 10gig, doing well over 1gbit/sec. For various reasons this solution is unsatisfactory; the VACL doesn't work well and doesn't support IPv6, SPAN sessions are limited and policy routing to a web cache is exactly what we don't want to do. What other solutions can people recommend? I see that GigaMon make an interesting (and expensive looking) product: http://www.gigamon.com/gigavue-420.php ...which claims to be able to tap a 10gig link, filter the traffic then direct it to a 1gig port. This could be interesting for a number of reasons. Other suggestions welcome. ___ 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] Monitoring HTTP / url access @10gig
We beta tested the GigaMon platform and for the most part it does what it claims it can do; basically takes a span feed and fans it out for analysis; in the end it was just too $$pricey$$ ( ~$100K USD); seems like the target mkt are carriers and large service providers. Our OITSecurity group has been looking at NetOptics as a less expensive alternative: http://www.network-taps.eu/home/home.php Does basically the same as the Gigamon but not nearly as expensive (~$50K USD); albeit with less bells and whistles. I forgot to mention that our focus is on IPS/IDS and these 10-gig feeds are to our IPS/IDS home grown clusters. Good luck. Regards, Ge Moua | Email: moua0...@umn.edu Network Design Engineer University of Minnesota | Networking Telecommunications Services Phil Mayers wrote: We currently monitor web access from our campus with a VACL capture, picked up by a server-class machine with a 10gig port. Hardware is sup720, and our internet links are 10gig, doing well over 1gbit/sec. For various reasons this solution is unsatisfactory; the VACL doesn't work well and doesn't support IPv6, SPAN sessions are limited and policy routing to a web cache is exactly what we don't want to do. What other solutions can people recommend? I see that GigaMon make an interesting (and expensive looking) product: http://www.gigamon.com/gigavue-420.php ...which claims to be able to tap a 10gig link, filter the traffic then direct it to a 1gig port. This could be interesting for a number of reasons. Other suggestions welcome. ___ 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/ ___ 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] Monitoring HTTP / url access @10gig
Ge Moua wrote: We beta tested the GigaMon platform and for the most part it does what it claims it can do; basically takes a span feed and fans it out for analysis; in the end it was just too $$pricey$$ ( ~$100K USD); seems like the target mkt are carriers and large service providers. Our OITSecurity group has been looking at NetOptics as a less expensive alternative: http://www.network-taps.eu/home/home.php Does basically the same as the Gigamon but not nearly as expensive (~$50K USD); albeit with less bells and whistles. Which specific products are you using, if you don't mind my asking? ___ 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] Monitoring HTTP / url access @10gig
I'm a bit surprise you were not able to match on IPv6 addresses; will something like this get any IPv6 traffic at all? ipv6 access-list IPv6-Sample-ACL permit ipv6 any any To answer your question: current: * Vlan based SPANs, with edge feed on dot.1q trunk; this allows for poor man granularity by vlan (permit all not as good as VACL) * IDS are open-bsd running snort with extensive ruleset for matching attack signatures not-so-distant-future (which will buy as a few years): * net-optics In my opinion all of this is analogous to an arms race where at some point traffic volume over-runs current method or technology used then the whole design needs to be re-visited again; but then again IT is somewhat like that by nature. Regards, Ge Moua | Email: moua0...@umn.edu Network Design Engineer University of Minnesota | Networking Telecommunications Services 2218 University Ave SE | Minneapolis, MN 55414-3029 Office: 612.626.2779 | Pager: 612.648.0103 | Fax: 612.626.1818 Phil Mayers wrote: Ge Moua wrote: We beta tested the GigaMon platform and for the most part it does what it claims it can do; basically takes a span feed and fans it out for analysis; in the end it was just too $$pricey$$ ( ~$100K USD); seems like the target mkt are carriers and large service providers. Our OITSecurity group has been looking at NetOptics as a less expensive alternative: http://www.network-taps.eu/home/home.php Does basically the same as the Gigamon but not nearly as expensive (~$50K USD); albeit with less bells and whistles. Which specific products are you using, if you don't mind my asking? ___ 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] Monitoring HTTP / url access @10gig
Ge Moua wrote: I'm a bit surprise you were not able to match on IPv6 addresses; will something like this get any IPv6 traffic at all? It's complicated, but seemingly the 6500 won't VACL-capture IPv6 traffic which it's also routing. It could be a bug, but as I say we've had other problems with VACL capture (e.g. it just stopped working one day with no config changes, then started back up a week later with no explanation) so we're keen to move away from it. ___ 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] Monitoring HTTP / url access @10gig
What code are you running on the Sup720 (3bxl ? I assume) ?? Regards, Ge Moua | Email: moua0...@umn.edu Network Design Engineer University of Minnesota | Networking Telecommunications Services Phil Mayers wrote: Ge Moua wrote: I'm a bit surprise you were not able to match on IPv6 addresses; will something like this get any IPv6 traffic at all? It's complicated, but seemingly the 6500 won't VACL-capture IPv6 traffic which it's also routing. It could be a bug, but as I say we've had other problems with VACL capture (e.g. it just stopped working one day with no config changes, then started back up a week later with no explanation) so we're keen to move away from it. ___ 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] Monitoring HTTP / url access @10gig
Ge Moua wrote: What code are you running on the Sup720 (3bxl ? I assume) ?? 12.2(33)SXI, but we've seen other problems on other versions; I don't have an exhaustive list, to hand. The config is something along the lines of: vlan access-map v6_Capture 10 match mac address PERMIT_ANY action forward capture vlan access-map v4_capture 10 match ip address WEB_TRAFFIC action forward capture vlan access-map v4_capture 20 match ip address PERMIT_ANY action forward vlan filter v6_capture vlan-list 4000 vlan filter v4_capture vlan-list 4001 int Vlan4000 description ipv6 upstream ipv6 address 2001:db8:100::1/126 int Vlan4001 description ipv4 upstream ipv6 address 192.0.2.1 255.255.255.252 int Te1/1 switchport mode trunk switchport trunk allowed vlan 4000,4001 ...now, this all *used* to work when we had: int Vlan4000 description layer2 only vlan, goes to ipv6 router no ip address mac packet-classify ...that latter line is *ABSOLUTELY* necessary, as is the no-IP SVI. Once we moved the routing onto the 6500, no combination of config would make VACL capture the ipv6. ___ 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] sliding window quota
There's also the Citrix Wan Scaler appliance (old Orbital Data) and the offering from Asankya. -- Just my $.02, your mileage may vary, batteries not included, etc ___ 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] DWDM optics on 6500s
If you want to cut delay for switching, you may want to consider the new top-of-rack 10G boxes, which are typically cut-through. You may find I'm thinking about that for within the datacenter. It's hard finding a justification for the C-vendor's products though - a N7 is just too much, and I guess the N5 is OK but even starting out it's not... inexpensive, esp when it doesn't even include a meaningful layer-3 capability. I guess I understand the product reasoning - a large datacenter is built around N7Ks, with N5K distro - which is great, if you have a massive datacenter... but what about us poor saps in the middle and lower tiers? Or aren't we interesting anymore? Oh, I understand, we're supposed to be virtualizing and buying the 1000v switches...except virtual servers don't do me crap for good... Personally, I have a bit of a thing against X2, but that's just me. Make your own mind up. Fair enough. 3) Does 6500 switching performance blow super-hard, or just so-so hard? (6-15us is ok.) Yes a 4900M might be faster, or a J-product, but I don't want to change platform really, I need NAT and don't want to use routers, I want to keep box count down (co-lo), and having a whole box just for passing 10G doesn't IMO make sense because I'd still have to get it into the 6500 anyway. The 6500 is a great 1G switch platform, but doesn't excel in the 10G range, particularly with 6704 blades. Admittedly, for the cost, I can buy an arista 1U for wave passthru and just tap multiple 1Gs over to the 6500. Why particularly with 6704 blades? Is there something particularly wrong with them? Thanks, -bacon ___ 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] DWDM optics on 6500s
On 05/10/2009 15:35, Jeff Bacon wrote: Admittedly, for the cost, I can buy an arista 1U for wave passthru and just tap multiple 1Gs over to the 6500. Aristas use SFP+. Good luck running colours over them. :-) Actually, Optoway in Taiwan produce CWDM SFP+ transceivers. I don't know anyone using them, but given the power constraints imposed by the SFP+ form factor, I wouldn't expect long reach or anything. Why particularly with 6704 blades? Is there something particularly wrong with them? Depends on what you do with them. They are a first generation blade, and are 6yo technology at this stage and, well, things have moved on since 2003. XENPAK is moribund as a transceiver type which means that any money you invest into buying transceivers will probably be written off when you retire the blade. If you're concerned about storm control (which personally, I am), the 6704 can only limit to 0.33% of port capacity, which means that if you get a broadcast / multicast storm on a 6704 port, it will bang out 33 megs of data before storm control even notices. Most hosts will happily ignore the multicast traffic, but the broadcast traffic could cause serious trouble. If you need to push wire-speed 10G on a 6704, there are conflicting reports as to whether this works well. Some people say yes; others no - there's lots of discussion about this in the c-nsp archives. It can help to use a DFC if you're banging out a lot of traffic, but that's extra €€€ on top of a product which already has a high cost per port. The 6708 is lots better than the 6704 if you operate it in non- oversubscribe mode, apart from anything else, it has a built-in DFC, which means that you don't need to retrofit this for high traffic environments. As I said, it depends on what you want to do. If you're running just a couple of gigs and don't care about the broadcast traffic problem or, say, are using them for L3 traffic instead of L2, then they are great. Similarly, the C65k+sup720 platform makes a really nice high density, feature rich 1G platform. But if you're planning to run lots of very high bandwidth stuff, it might be better to use a different platform. Nick ___ 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] DWDM optics on 6500s
In order to use SFP+ from other vendors in Arista, you need to get them enabled first. -Azher Nick Hilliard wrote: On 05/10/2009 15:35, Jeff Bacon wrote: Admittedly, for the cost, I can buy an arista 1U for wave passthru and just tap multiple 1Gs over to the 6500. Aristas use SFP+. Good luck running colours over them. :-) Actually, Optoway in Taiwan produce CWDM SFP+ transceivers. I don't know anyone using them, but given the power constraints imposed by the SFP+ form factor, I wouldn't expect long reach or anything. Why particularly with 6704 blades? Is there something particularly wrong with them? Depends on what you do with them. They are a first generation blade, and are 6yo technology at this stage and, well, things have moved on since 2003. XENPAK is moribund as a transceiver type which means that any money you invest into buying transceivers will probably be written off when you retire the blade. If you're concerned about storm control (which personally, I am), the 6704 can only limit to 0.33% of port capacity, which means that if you get a broadcast / multicast storm on a 6704 port, it will bang out 33 megs of data before storm control even notices. Most hosts will happily ignore the multicast traffic, but the broadcast traffic could cause serious trouble. If you need to push wire-speed 10G on a 6704, there are conflicting reports as to whether this works well. Some people say yes; others no - there's lots of discussion about this in the c-nsp archives. It can help to use a DFC if you're banging out a lot of traffic, but that's extra €€€ on top of a product which already has a high cost per port. The 6708 is lots better than the 6704 if you operate it in non- oversubscribe mode, apart from anything else, it has a built-in DFC, which means that you don't need to retrofit this for high traffic environments. As I said, it depends on what you want to do. If you're running just a couple of gigs and don't care about the broadcast traffic problem or, say, are using them for L3 traffic instead of L2, then they are great. Similarly, the C65k+sup720 platform makes a really nice high density, feature rich 1G platform. But if you're planning to run lots of very high bandwidth stuff, it might be better to use a different platform. Nick ___ 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/ ___ 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] Invitation to connect on LinkedIn
LinkedIn Zahid Hassan pidió añadirte como contacto en LinkedIn: -- Sebastián, I'd like to add you to my professional network on LinkedIn. - Zahid Aceptar invitación de Zahid Hassan http://www.linkedin.com/e/vyPV953ymgwhJZim_QSTkIEJ407GCYbmqcvZFAK/blk/I1483081203_2/pmpxnSRJrSdvj4R5fnhv9ClRsDgZp6lQs6lzoQ5AomZIpn8_cBYPc38Ne30Pe3gNiiZTlPlIgABArOYRdzoUdzwUdPsLrCBxbOYWrSlI/EML_comm_afe/ Ver invitación de Zahid Hassan http://www.linkedin.com/e/vyPV953ymgwhJZim_QSTkIEJ407GCYbmqcvZFAK/blk/I1483081203_2/39vcP0OcjwMcPwQckALqnpPbOYWrSlI/svi/ -- ¿Por qué puede ser una buena idea conectar con Zahid Hassan? La gente que conoce a Zahid Hassan podría descubrir tu perfil: Conectar con Zahid Hassan atraerá la atención de otros usuarios de LinkedIn. Averigua quién ha visto tu perfil: http://www.linkedin.com/e/wvp/inv18_wvmp/ -- (c) 2009, LinkedIn Corporation ___ 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] Invitation to connect on LinkedIn
Fail. Zahid Hassan wrote: LinkedIn Zahid Hassan pidió añadirte como contacto en LinkedIn: -- Sebastián, I'd like to add you to my professional network on LinkedIn. - Zahid Aceptar invitación de Zahid Hassan http://www.linkedin.com/e/vyPV953ymgwhJZim_QSTkIEJ407GCYbmqcvZFAK/blk/I1483081203_2/pmpxnSRJrSdvj4R5fnhv9ClRsDgZp6lQs6lzoQ5AomZIpn8_cBYPc38Ne30Pe3gNiiZTlPlIgABArOYRdzoUdzwUdPsLrCBxbOYWrSlI/EML_comm_afe/ Ver invitación de Zahid Hassan http://www.linkedin.com/e/vyPV953ymgwhJZim_QSTkIEJ407GCYbmqcvZFAK/blk/I1483081203_2/39vcP0OcjwMcPwQckALqnpPbOYWrSlI/svi/ -- ¿Por qué puede ser una buena idea conectar con Zahid Hassan? La gente que conoce a Zahid Hassan podría descubrir tu perfil: Conectar con Zahid Hassan atraerá la atención de otros usuarios de LinkedIn. Averigua quién ha visto tu perfil: http://www.linkedin.com/e/wvp/inv18_wvmp/ -- (c) 2009, LinkedIn Corporation ___ 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/ -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 ___ 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] does PBR apply to traffic from connected interfaces to router itself?
I'm doing some tests and i have a case where a vpdn user is able to send snmp requests to the router's loopback where he's connected, although i have a route-map under his vtemplate sending all snmp to null0. I have verified that snmp cannot go outside of router (so route-map is indeed working), but i had the impression that he shouldn't be able to snmp anobody, including the router itself. There is a trick, because vtemplate is using Loopback's ip, but i don't know if that's the reason snmp is allowed to bypass the route-map. ip access-list extended SNMP-ACL permit udp any any eq snmp route-map TEST-ROUTEMAP permit 10 match ip address SNMP-ACL set interface Null0 interface Virtual-Template1 ip unnumbered Loopback0 ip policy route-map TEST-ROUTEMAP Router is a 7200 running 12.2(31)SB14. I'm going to repeat the test using icmp, but it seems quite strange until now. PS1 : Local PBR is used for router generated traffic (router=src), so it shouldn't have any effect in my case. PS2 : I know there are other ways to stop snmp traffic from reaching the router or to block snmp traffic leaving an interface, but that's not my issue right now. -- Tassos ___ 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] Invitation to connect on LinkedIn
Alex Balashov wrote: Fail. Fail indeed. Why anyone would provide their email password to sites which guarantee to spam every address they can find 1s surprising. Why anyone on this list would do so is mind-boggling. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ 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] Enclosed rack with filtered air
A minor reconfiguration to positive pressure would prevent dust from getting sucked in. Put the filter on the bottom, then the fan drawing air through the filter, then it will create a small pressure inside the cabient, keeping dust out, except that which might leak through or around the filter element. On Sat, Oct 03, 2009 at 10:37:28AM -0500, scott owens wrote: Hello, I need to put two 6509s in a non-clean warehouse. I thought I could just put them in a standard rack with some AC filters attached to the bottom and let the air get pulled out of the top. However the rack is not airtight enough and I am getting a lot of drywall/dust in the rack and switches. Anyone here know where / how to find a semi-sealed enclosed rack with filtered forced air ? ___ 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/ -- /* Jason Philbrook | Midcoast Internet Solutions - Wireless and DSL KB1IOJ| Broadband Internet Access, Dialup, and Hosting http://f64.nu/ | for Midcoast Mainehttp://www.midcoast.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/
[c-nsp] Invitation to connect on LinkedIn
LinkedIn Inder Rishi Singh Kochar pidió añadirte como contacto en LinkedIn: -- Sebastián, I'd like to add you to my professional network on LinkedIn. - Inder Rishi Singh Aceptar invitación de Inder Rishi Singh Kochar http://www.linkedin.com/e/vyPV953ymgwhJZim_QSTkIEJ407GCYbmqcvZFAK/blk/I1482978773_2/pmpxnSRJrSdvj4R5fnhv9ClRsDgZp6lQs6lzoQ5AomZIpn8_cBYPdPsUdPAOe3gNiiZhj5kUrnpOtiYSdz8Rc3wUdPsLrCBxbOYWrSlI/EML_comm_afe/ Ver invitación de Inder Rishi Singh Kochar http://www.linkedin.com/e/vyPV953ymgwhJZim_QSTkIEJ407GCYbmqcvZFAK/blk/I1482978773_2/39vcPsTe3sVczwQckALqnpPbOYWrSlI/svi/ -- ¿Por qué puede ser una buena idea conectar con Inder Rishi Singh Kochar? Los contactos de Inder Rishi Singh Kochar podrían serte útiles: Tras aceptar la invitación de Inder Rishi Singh Kochar, revisa los contactos de Inder Rishi Singh Kochar para ver a quién más conoces y a quién te gustaría que te presentaran. Forjar contactos puede crear oportunidades futuras. -- (c) 2009, LinkedIn Corporation ___ 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] facebook related
Which Cisco router are you? [obnoxious moving graphics] Congratulation; You are the 7500 series; you are power hungry, warm, impressive looking, and traditional. Watch out; Geeks are attracted to your pretty color and impressive presence. See what routers your friends are. If you want to know someone's IP address, send them in a message a unique URL to visit (or inline hyperlinked image in email) from a webserver you control, then watch the logs for their visit. On Thu, Oct 01, 2009 at 01:06:16PM -0700, Tony Tauber wrote: Aww. I thought this was going to introduce the Facebook app IOS Upgrade Manager which enables you to navigate www.cisco.com by using Facebook. Answer burning questions like : If your friends were IOS software, which train/version would they be? Or games like Two of your friends configured EIGRP using Protocol Wars. Well, there's still hope for the future. Tony On Thu, Oct 01, 2009 at 01:07:22PM -0400, Justin M. Streiner wrote: On Thu, 1 Oct 2009, Mohammad Khalil wrote: I was asked today if i recieved a message on facebook can i know the ip address of the sender My guess is that you will not see the IP address of the sender when you receive a message through Facebook. Facebook doesn't present full message headers on messages that are sent through the website. Since all communication happens through the website, that provides a layer of abstraction if Facebook/Myspace/insert_portal_here chooses not to reveal the sender's IP address to you. ___ 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/ -- /* Jason Philbrook | Midcoast Internet Solutions - Wireless and DSL KB1IOJ| Broadband Internet Access, Dialup, and Hosting http://f64.nu/ | for Midcoast Mainehttp://www.midcoast.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] DWDM optics on 6500s
On Mon, Oct 05, 2009 at 04:06:31PM +0100, Nick Hilliard wrote: Depends on what you do with them. They are a first generation blade, and are 6yo technology at this stage and, well, things have moved on since 2003. XENPAK is moribund as a transceiver type which means that any money you invest into buying transceivers will probably be written off when you retire the blade. Don't forget they are absurdly under-buffered (16MB per card, compared to 256MB for 6708), and you can easily cause head of line blocking with certain traffic profiles. If you want to run anywhere close to line rate on them you need to monitor for drops or overruns and be prepared to play the port shuffle game to find an arrangement that works. Passing a lot of traffic within the same fabric channel (from port 1-2, or 3-4) is the biggest sin, it will start dropping at 7 Gbps. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] DWDM optics on 6500s
Don't forget they are absurdly under-buffered (16MB per card, compared to 256MB for 6708), and you can easily cause head of line blocking with certain traffic profiles. If you want to run anywhere close to line rate on them you need to monitor for drops or overruns and be prepared to play the port shuffle game to find an arrangement that works. Passing a lot of traffic within the same fabric channel (from port 1-2, or 3-4) is the biggest sin, it will start dropping at 7 Gbps. Well that's wonderfully comforting. Though I really probably only need two ports anyway - ring-in and ring-out. Maybe not so bad. I'd consider a 720-VS-10G head if I had some confidence that those two ports on the sup were actually connected to the fabric. I don't really need to run line rate - this is more about latency and burst capacity than sustained throughput. I have loads that burst from 0 to 500Mb/sec (then back) in nothing flat, and multiple of those may run through the wire at the same time. Or not. Someone pointed out that the X2 and SFP+ xcvrs don't have much punch, and I'm going to be shooting 20-30km through passive MUXes. So that might matter. (This is a bit of a roll-yer-own local metro NYC ring, which I'm doing because I can get the wave for not much more than I'd pay for the switched gig.) ___ 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] Will UDLD work with converters ?
Mark Tinka wrote: We've seen strange issues with converters were providers were unable to guarantee Jumbo frame MTU sizes because the media converters don't support them - what the hell... This happened to me with Versitron MCs. I had a set in production that worked perfectly fine. Then one day BGP started flapping. A lengthy period of time for troubleshooting later it was finally determined that the damn MCs suddenly started filtering jumbos in only 1 direction. I hope that doesn't hold true for some of my other more important Versitron GigE links where I have 8 of the very same model back to back... Justin ___ 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] DWDM optics on 6500s
On Mon, Oct 05, 2009 at 03:47:05PM -0500, Jeff Bacon wrote: Well that's wonderfully comforting. Though I really probably only need two ports anyway - ring-in and ring-out. Maybe not so bad. I'd consider a 720-VS-10G head if I had some confidence that those two ports on the sup were actually connected to the fabric. Can't tell you anything about the VS-10G, but if you're doing it on 6704 make sure you use 1 and 3, or 2 and 4, not 1-2 etc. Unfortunately I have to deal with many hundreds of 10GE ports on 6704s (what can I say, they're cheap :P), so we tend to try to pair them up as port-channels (i.e. members 1/1 and 1/2, 2/1 and 2/2, etc) since this guarantees traffic will never go in port 1 and out port 2 on any given fabric channel. I don't really need to run line rate - this is more about latency and burst capacity than sustained throughput. I have loads that burst from 0 to 500Mb/sec (then back) in nothing flat, and multiple of those may run through the wire at the same time. Or not. Yeah ok that won't challenge pretty much any hardware. :) Someone pointed out that the X2 and SFP+ xcvrs don't have much punch, and I'm going to be shooting 20-30km through passive MUXes. So that might matter. X2 is nothing more than a physically smaller XENPAK case, the interface and for the most part the components (if you take apart a modern XENPAK, you'll see most of it is empty space) are exactly the same. Basically X2 only exists so lazy companies who don't want to redesign their boards (Hi Cisco!) can keep using the same components from their old XENPAK designs. SFP+ is an entirely different beast, two generations removed from XENPAK (XENPAK-XFP-SFP), and with very low max power caps which prevent it from being used for most long reach/DWDM applications. Basically SFP+ only exists so you can stuff 48 10GE ports into a blade or 1U switch, but it's really only useful if you need to do a large number of short reach ports (i.e. datacenter aggregation). The only redeeming quality of SFP+ is you can finally get LR for them (I won't touch SR outside of same-rack applications, way too many problems) at not unreasonable prices. XFP is still the best all-around optics platform for the full range of features, but unfortunately you'll see less and less focus here as everyone jumps on the SFP+ bandwagon as the next new thing even when it is completely unnecessary and infact only serves to limit function. Slightly dated now (from feb 08) but mostly still accurate: http://www.nanog.org/meetings/nanog42/presentations/pluggables.pdf -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] DWDM optics on 6500s
Well that's wonderfully comforting. Though I really probably only need two ports anyway - ring-in and ring-out. Maybe not so bad. I'd consider a 720-VS-10G head if I had some confidence that those two ports on the sup were actually connected to the fabric. The 10Gig ports on the VS-S720 are fabric attached. I don't really need to run line rate - this is more about latency and burst capacity than sustained throughput. I have loads that burst from 0 to 500Mb/sec (then back) in nothing flat, and multiple of those may run through the wire at the same time. Or not. I think lots of people are in the latency not bandwidth situation. That's probably why most vendors aren't producing dense 10Gig cards yet. We have the situation where GigE latency is too high for some apps, but 10Gig is okay. Someone pointed out that the X2 and SFP+ xcvrs don't have much punch, and I'm going to be shooting 20-30km through passive MUXes. So that might matter Opnext claims ER SFP+. Haven't seen anyone doing ZR or anything more exotic yet. Sure it will come though. Something FEC/EFEC in the 200km range would be interesting for many people. -- Tim: Sent from New York, NY, United States ___ 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] DWDM optics on 6500s
We've selected the 6708 for our 10Gig installs. DFCs and good sized buffers. Lots of availability on the used market. Can be run in line-rate or over-subscribed mode, which might suit your deployment. I have hopes for SFP+ linecards to drive 10Gig costs down, but I don't think much is going to happen until 40Gig/100Gig is the new backbone. Tim: On Mon, Oct 5, 2009 at 4:47 PM, Jeff Bacon ba...@walleyesoftware.com wrote: Don't forget they are absurdly under-buffered (16MB per card, compared to 256MB for 6708), and you can easily cause head of line blocking with certain traffic profiles. If you want to run anywhere close to line rate on them you need to monitor for drops or overruns and be prepared to play the port shuffle game to find an arrangement that works. Passing a lot of traffic within the same fabric channel (from port 1-2, or 3-4) is the biggest sin, it will start dropping at 7 Gbps. Well that's wonderfully comforting. Though I really probably only need two ports anyway - ring-in and ring-out. Maybe not so bad. I'd consider a 720-VS-10G head if I had some confidence that those two ports on the sup were actually connected to the fabric. I don't really need to run line rate - this is more about latency and burst capacity than sustained throughput. I have loads that burst from 0 to 500Mb/sec (then back) in nothing flat, and multiple of those may run through the wire at the same time. Or not. Someone pointed out that the X2 and SFP+ xcvrs don't have much punch, and I'm going to be shooting 20-30km through passive MUXes. So that might matter. (This is a bit of a roll-yer-own local metro NYC ring, which I'm doing because I can get the wave for not much more than I'd pay for the switched gig.) ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Tim: Sent from New York, NY, United States ___ 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] DWDM optics on 6500s
On Monday 05 October 2009 11:06:31 pm Nick Hilliard wrote: As I said, it depends on what you want to do. If you're running just a couple of gigs and don't care about the broadcast traffic problem or, say, are using them for L3 traffic instead of L2, then they are great. Similarly, the C65k+sup720 platform makes a really nice high density, feature rich 1G platform. But if you're planning to run lots of very high bandwidth stuff, it might be better to use a different platform. From Cisco, I think that if the goal is to aggregate n x 10Gbps Ethernet in abundance, for pure Layer 2 core switching over a limited distance (within the data centre), the Nexus 5000 might not be such a bad consideration. Preliminary pricing for this vs. a couple of WS-X6708 is comparable, and better in certain cases. YMMV. That said, it's also clear the 6500 isn't done yet, and it's still got a number of tricks up its sleeve. The question is, Will you wait?. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ 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] does PBR apply to traffic from connected interfaces to router itself?
On Mon, 2009-10-05 at 22:49 +0300, Tassos Chatzithomaoglou wrote: I'm doing some tests and i have a case where a vpdn user is able to send snmp requests to the router's loopback where he's connected, although i have a route-map under his vtemplate sending all snmp to null0. I have verified that snmp cannot go outside of router (so route-map is indeed working), but i had the impression that he shouldn't be able to snmp anobody, including the router itself. There is a trick, because vtemplate is using Loopback's ip, but i don't know if that's the reason snmp is allowed to bypass the route-map. ip access-list extended SNMP-ACL permit udp any any eq snmp route-map TEST-ROUTEMAP permit 10 match ip address SNMP-ACL set interface Null0 interface Virtual-Template1 ip unnumbered Loopback0 ip policy route-map TEST-ROUTEMAP Router is a 7200 running 12.2(31)SB14. I'm going to repeat the test using icmp, but it seems quite strange until now. PS1 : Local PBR is used for router generated traffic (router=src), so it shouldn't have any effect in my case. PS2 : I know there are other ways to stop snmp traffic from reaching the router or to block snmp traffic leaving an interface, but that's not my issue right now. Cisco loopback interfaces are not like normal interfaces. Apply the policy globally using the ip local policy route-map TEST-ROUTEMAP command. Royal pain because if you have multiple loopbacks and want a different policy on each, you need to define all choices in a single monster policy. Vince -- Vincent C Jones Networking Unlimited, Inc 14 Dogwood Lane, Tenafly NJ Voice: 201 568-7810 ___ 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/
