[c-nsp] amend the work time after a call has been completed.
Hi, Is it possible to amend the work time after a call has been completed. For example I want to be able to check what the current work time is after a call, say 20 seconds, and I want to increase it to say 30 seconds before the next call comes through. This is one of my ticket. I am not sure whether call manager can perform the above mentioned task. Any suggestions? Thanks Hemal ___ 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] Will this work?
I've been asked if this will work. I would think that it would but I would like a second opinion. 7206 VXR with an NPE-400, 512Mb ram, C7200 I/O 2FE/E card and two PA-MC-T3s. The PA-MC-T3s are 90 Bandwidth points each and the I/O controller counts as 400. There would be some MLPPP Bundles and some basic QOS. The only ACLs in the box would be to protect the box it's self and the occasional SMTP block for a user that won't clean up their network. I am basically trying to merge two non VXR 7206s with NPE-150s into one box. Richey ___ 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 this work?
Richey wrote: I've been asked if this will work. I would think that it would but I would like a second opinion. 7206 VXR with an NPE-400, 512Mb ram, C7200 I/O 2FE/E card and two PA-MC-T3s. The PA-MC-T3s are 90 Bandwidth points each and the I/O controller counts as 400. There would be some MLPPP Bundles and some basic QOS. The only ACLs in the box would be to protect the box it's self and the occasional SMTP block for a user that won't clean up their network. We have several of this exact setup as customer T1 aggregation routers with no issues. We're using OSPF for the infrastructure and iBGP for customer routes. NPE300 will even work as long as you don't have a large percentage of the T1s as multilink. Put your PA-MC-T3s in the even numbered slots. -- 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] Will UDLD work with converters ?
Nick Hilliard wrote: On 02/10/2009 15:24, Zoe O'Connell wrote: It's worth noting that while the restriction on optics in general is just annoying, the DOM restrictions do seem to be there for a reason: I have a number of non-Cisco optics reporting DOM data that's obviously incorrect, so I don't trust anything that's non-Cisco. Sadly, on platforms where it will show you DOM from any SFP, there's no obvious indication if it's a Cisco or third party optic. show idprom interface gig x/y should give you a pretty good idea of what's plugged into the box (on a 65k). Yes, there are very poor quality transceivers out there. Cisco appears to re-sell Finisar and Opnext, which would suggest that these companies produce good quality kit. I'm personally not convinced that restricting equipment to use own-brand transceivers does much more than create a lucrative grey market for sophisticated knock-offs. I've also heard the incorrect DOM readings line being trotted out before, but I'm not convinced by it: if you buy cheap-ass equipment, you should expect high mileage variation. FWIW: I have a great many Cisco SFPs sourced via Dimension Data (at ridiculously over-inflated cost, of course). I get varying degrees of bullshit back as DOM readings from quite a few of them. Sounds like more FUD to me. adam. ___ 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: On Friday 02 October 2009 10:27:37 pm Justin Shore wrote: It seems to me that there should be a standards body within Cisco that should mandate certain minimum requirements of all product lines. If and when there is the ability for BUs and product lines to share common and trivial products like SFPs then they should require it. It would save them RD and QA money if nothing else. This is the thing I really like about J. Across a specific series of platforms, e.g., M/T/MX, all optics are shared, including SFP-to-copper modules. It's a real pity when you can no longer take such simple pleasures for granted. I think Cisco's SPA technology is a step in the right direction re: optical modules, since they're all shared among the various platforms that support this interface model, but I wonder how many of Cisco's customers will be moving to the SIP/SPA format soon (and it likely won't be because of common SFP/XFP sparing). SPA allows them to keep costs in the stratosphere though, nothing like 6700 LAN cards in a SPA world... adam. ___ 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] Will UDLD work with converters ?
On Friday 02 October 2009 10:15:56 pm Gert Doering wrote: We'd stay away from converters, and better get 3rd-party ZX optics instead. Agree. 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... 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] Will UDLD work with converters ?
On Friday 02 October 2009 10:27:37 pm Justin Shore wrote: It seems to me that there should be a standards body within Cisco that should mandate certain minimum requirements of all product lines. If and when there is the ability for BUs and product lines to share common and trivial products like SFPs then they should require it. It would save them RD and QA money if nothing else. This is the thing I really like about J. Across a specific series of platforms, e.g., M/T/MX, all optics are shared, including SFP-to-copper modules. It's a real pity when you can no longer take such simple pleasures for granted. I think Cisco's SPA technology is a step in the right direction re: optical modules, since they're all shared among the various platforms that support this interface model, but I wonder how many of Cisco's customers will be moving to the SIP/SPA format soon (and it likely won't be because of common SFP/XFP sparing). 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] Will UDLD work with converters ?
Also, bear in mind that not all c65k ports support reading DDM info from SFPs. SUP720 cards will, as will later hardware revisions of the 6724sfp blades. Earlier hardware revisions won't. Yeah. I really wish this had gone under a new part number (WS-X6724A-SFP?). It hasn't happened yet, but I dread having to RMA one of our HW rev = 3.0 cards. Does anyone know if RMA requests can specify minimum hardware rev's? With regards to bogus values, I was going to illustrate some brokenness with null thresholds from some DOM devices (at least one batch of Cisco X2's), but it looks like this got fixed between SXH and SXI. ___ 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] Will UDLD work with converters ?
Is there any issues with running UDLD with TX to Fiber converters at each end of a gig cisco to cisco link? We are just over the distance budget with the 10KM optics. 6500 TX port--- to fiber converter--- 18KM fiber--- to converter--- back to TX port on 3750. We are looking at the converters because the Cisco ZX optics are very expensive and the converters with 30KM optics are much cheaper than the 60 KM ZX optics. Thanks in advance... Jeff Fitzwater OIT Network Systems Princeton University ___ 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 ?
On 02/10/2009 14:36, Jeff Fitzwater wrote: Is there any issues with running UDLD with TX to Fiber converters at each end of a gig cisco to cisco link? We are just over the distance budget with the 10KM optics. 6500 TX port--- to fiber converter--- 18KM fiber--- to converter--- back to TX port on 3750. We are looking at the converters because the Cisco ZX optics are very expensive and the converters with 30KM optics are much cheaper than the 60 KM ZX optics. UDLD should be fine - it's just data packets, after all. So unless your media converters are doing something very strange and very wrong, it will be fine. You may want to look at third party optics from reputable manufacturers (e.g. http://www.finisar.com/optical_modules_2), although many organisations have policies in place which work against using third party components. Also, it is very easy to pick up grey optics with cisco serial numbers on them, which means that the special command which we all know about isn't necessary. Also, bear in mind that not all c65k ports support reading DDM info from SFPs. SUP720 cards will, as will later hardware revisions of the 6724sfp blades. Earlier hardware revisions won't. Also, 12.2SX = SXF9 will not present DDM unless it sees a Cisco serial number. 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] Will UDLD work with converters ?
Hi, On Fri, Oct 02, 2009 at 09:36:19AM -0400, Jeff Fitzwater wrote: Is there any issues with running UDLD with TX to Fiber converters at each end of a gig cisco to cisco link? We are just over the distance budget with the 10KM optics. As far as I remember, Cisco will never do UDLD on TX ports. We'd stay away from converters, and better get 3rd-party ZX optics instead. Converters are always trouble (autosensing yes/no? will it properly signal 'link down' when there is a problem with the other side? etc.). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgp4wNV08akN0.pgp Description: PGP signature ___ 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 ?
Nick Hilliard wrote: You may want to look at third party optics from reputable manufacturers (e.g. http://www.finisar.com/optical_modules_2), although many organisations have policies in place which work against using third party components. Also, it is very easy to pick up grey optics with cisco serial numbers on them, which means that the special command which we all know about isn't necessary. Also, bear in mind that not all c65k ports support reading DDM info from SFPs. SUP720 cards will, as will later hardware revisions of the 6724sfp blades. Earlier hardware revisions won't. Also, 12.2SX = SXF9 will not present DDM unless it sees a Cisco serial number. It's worth noting that while the restriction on optics in general is just annoying, the DOM restrictions do seem to be there for a reason: I have a number of non-Cisco optics reporting DOM data that's obviously incorrect, so I don't trust anything that's non-Cisco. Sadly, on platforms where it will show you DOM from any SFP, there's no obvious indication if it's a Cisco or third party optic. ___ 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 ?
I can personally recommend SmartOptics. A norwegian company selling transeivers with cisco blueprint at low cost. http://www.smartoptics.com/ List price SFP, 1.25 Gbps Gigabit Ethernet, 1310nm, SM/MM, DDM, 20dB, 40km $533 compared to Cisco's $3995 for their ZX In the end their cisco/smartoptics/finisar is probably made on the same factory, so it's only a matter of company policy. You should though consider Cisco's third party policy before making your decision, http://www.cisco.com/en/US/prod/prod_warranty09186a00800b5594.html // Ulrich -Oprindelig meddelelse- Fra: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] På vegne af Nick Hilliard Sendt: 2. oktober 2009 16:06 Til: cisco-nsp@puck.nether.net Emne: Re: [c-nsp] Will UDLD work with converters ? On 02/10/2009 14:36, Jeff Fitzwater wrote: Is there any issues with running UDLD with TX to Fiber converters at each end of a gig cisco to cisco link? We are just over the distance budget with the 10KM optics. 6500 TX port--- to fiber converter--- 18KM fiber--- to converter--- back to TX port on 3750. We are looking at the converters because the Cisco ZX optics are very expensive and the converters with 30KM optics are much cheaper than the 60 KM ZX optics. UDLD should be fine - it's just data packets, after all. So unless your media converters are doing something very strange and very wrong, it will be fine. You may want to look at third party optics from reputable manufacturers (e.g. http://www.finisar.com/optical_modules_2), although many organisations have policies in place which work against using third party components. Also, it is very easy to pick up grey optics with cisco serial numbers on them, which means that the special command which we all know about isn't necessary. Also, bear in mind that not all c65k ports support reading DDM info from SFPs. SUP720 cards will, as will later hardware revisions of the 6724sfp blades. Earlier hardware revisions won't. Also, 12.2SX = SXF9 will not present DDM unless it sees a Cisco serial number. 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/
Re: [c-nsp] Will UDLD work with converters ?
Jeff Fitzwater wrote: Is there any issues with running UDLD with TX to Fiber converters at each end of a gig cisco to cisco link? We are just over the distance budget with the 10KM optics. 6500 TX port--- to fiber converter--- 18KM fiber--- to converter--- back to TX port on 3750. Should work fine. I'm doing the same thing over several back to back media converters with 80k optics. I'd love to replace the MCs with something better but otherwise UDLD works fine over them. We are looking at the converters because the Cisco ZX optics are very expensive and the converters with 30KM optics are much cheaper than the 60 KM ZX optics. Agreed. This is on my list of major Cisco gripes. 10km is laughable in the SP world. Where are the 20k and 40k optics? Where are the 80k and 110k optics? Cabletron had 110k optics a decade ago. The single-strand Cisco GigE optic is limited to 10km too. Single-strand optics are critical in the SP world. Not everyone has excess bundles of dark fiber to play with to turn up a simple GigE link. I understand that Cisco wouldn't sell a lot of these since most of their business is enterprise. I get that. I would suggest that they pick a well-known and reliable SFP manufacturer like Champion and support their optics. Fill in the void with someone else's gear if you don't think the cost would justify the benefits of doing it yourself. There are other ways to do things besides doing it all in-house. Another major Cisco SFP gripe I have is that some BUs require optics that no other BU supports which makes common sparing across your product lines impossible. The ONSs require specific optics. The GLC- and SFP- that the switches and routers support don't work in ONS's LCs like the XPonder. We've found that the SFP- optics aren't supported in some switches with older code. DOM isn't universally supported so why pay for thee DOM optic when your switch or linecard doesn't support it. DWDM SFP support was added to some switches in the later 12.2(40+)SE releases such as 12.2(46)SE for the ME3750. However it wasn't added to all switches such as the 3560, 3750, or 2960 but it was added to the 3560/3750 E series. The beefy 4948s and monster 4900Ms are still out in the cold on DWDM support for SFPs too (I know that the 10G X2 optic supports DWDM). It seems to me that there should be a standards body within Cisco that should mandate certain minimum requirements of all product lines. If and when there is the ability for BUs and product lines to share common and trivial products like SFPs then they should require it. It would save them RD and QA money if nothing else. Back to your question though, yes UDLD should work fine over MCs. 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] Will UDLD work with converters ?
[100% agreed on rant. ghods, it is so depressing to fork out for cisco optics and find that they don't work on other cisco gear]. On 02/10/2009 15:27, Justin Shore wrote: Back to your question though, yes UDLD should work fine over MCs. as someone else noted, only for optical transceivers. TX does not support UDLD (which was what the original poster was wondering about). 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] Will UDLD work with converters ?
According to the doc if I am using a TX port the DEFAULT is UDLD DISABLED, so I have to enable it and also it states that I need to run in AGGRESSIVE MODE when using TX. I think I read that correct! Jeff On Oct 2, 2009, at 11:30 AM, Jeff Fitzwater wrote: Why do you say TX does not support UDLD? The doc and port configs support it. Am I missing something? Jeff On Oct 2, 2009, at 11:14 AM, Nick Hilliard wrote: [100% agreed on rant. ghods, it is so depressing to fork out for cisco optics and find that they don't work on other cisco gear]. On 02/10/2009 15:27, Justin Shore wrote: Back to your question though, yes UDLD should work fine over MCs. as someone else noted, only for optical transceivers. TX does not support UDLD (which was what the original poster was wondering about). 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/ ___ 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 ?
Why do you say TX does not support UDLD? The doc and port configs support it. Am I missing something? Jeff On Oct 2, 2009, at 11:14 AM, Nick Hilliard wrote: [100% agreed on rant. ghods, it is so depressing to fork out for cisco optics and find that they don't work on other cisco gear]. On 02/10/2009 15:27, Justin Shore wrote: Back to your question though, yes UDLD should work fine over MCs. as someone else noted, only for optical transceivers. TX does not support UDLD (which was what the original poster was wondering about). 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/
Re: [c-nsp] Will UDLD work with converters ?
On Fri, 02 Oct 2009 15:24:05 +0100, Zoe O'Connell wrote Nick Hilliard wrote: Also, bear in mind that not all c65k ports support reading DDM info from SFPs. SUP720 cards will, as will later hardware revisions of the 6724sfp blades. *Beware*, in SXI train, there's again a nasty IOS lock on 6724 cards: show inte gi 3/1 transceiver DOM is not supported on this linecard It's really odd that things that finally work as expected are again being disabled in software for no reason. It's worth noting that while the restriction on optics in general is just annoying, the DOM restrictions do seem to be there for a reason: I have a number of non-Cisco optics reporting DOM data that's obviously incorrect You get what you've paid for. If you're buying noname greymarket crap, DOM might be broken. With any decent SFP manufacturer, it works just fine. With kind regards, M. ___ 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 ?
Definitely avoid aggressive mode with converters, unless you've got errdisable recovery timers enabled. Otherwise if you reload one side, the other side will stop receiving UDLD but it's link is still up (from the converter), so it'll errdisable the port. Chuck -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeff Fitzwater Sent: Friday, October 02, 2009 11:42 AM To: Jeff Fitzwater Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Will UDLD work with converters ? According to the doc if I am using a TX port the DEFAULT is UDLD DISABLED, so I have to enable it and also it states that I need to run in AGGRESSIVE MODE when using TX. I think I read that correct! Jeff On Oct 2, 2009, at 11:30 AM, Jeff Fitzwater wrote: Why do you say TX does not support UDLD? The doc and port configs support it. Am I missing something? Jeff On Oct 2, 2009, at 11:14 AM, Nick Hilliard wrote: [100% agreed on rant. ghods, it is so depressing to fork out for cisco optics and find that they don't work on other cisco gear]. On 02/10/2009 15:27, Justin Shore wrote: Back to your question though, yes UDLD should work fine over MCs. as someone else noted, only for optical transceivers. TX does not support UDLD (which was what the original poster was wondering about). 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/ ___ 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] Will UDLD work with converters ?
We are looking at the converters because the Cisco ZX optics are very expensive and the converters with 30KM optics are much cheaper than the 60 KM ZX optics. Agreed. This is on my list of major Cisco gripes. 10km is laughable in the SP world. Where are the 20k and 40k optics? Where are the 80k and 110k optics? Cabletron had 110k optics a decade ago. The single-strand Cisco GigE optic is limited to 10km too. Single-strand optics are critical in the SP world. Not everyone has excess bundles of dark fiber to play with to turn up a simple GigE link. I understand that Cisco wouldn't sell a lot of these since most of their business is enterprise. I get that. I would suggest that they pick a well-known and reliable SFP manufacturer like Champion and support their optics. Fill in the void with someone else's gear if you don't think the cost would justify the benefits of doing it yourself. There are other ways to do things besides doing it all in-house. Another major Cisco SFP gripe I have is that some BUs require optics that no other BU supports which makes common sparing across your product lines impossible. The ONSs require specific optics. The GLC- and SFP- that the switches and routers support don't work in ONS's LCs like the XPonder. We've found that the SFP- optics aren't supported in some switches with older code. DOM isn't universally supported so why pay for thee DOM optic when your switch or linecard doesn't support it. DWDM SFP support was added to some switches in the later 12.2(40+)SE releases such as 12.2(46)SE for the ME3750. However it wasn't added to all switches such as the 3560, 3750, or 2960 but it was added to the 3560/3750 E series. The beefy 4948s and monster 4900Ms are still out in the cold on DWDM support for SFPs too (I know that the 10G X2 optic supports DWDM). It seems to me that there should be a standards body within Cisco that should mandate certain minimum requirements of all product lines. If and when there is the ability for BUs and product lines to share common and trivial products like SFPs then they should require it. It would save them RD and QA money if nothing else. Without derailing this discussion, I think the support of OEM vs Vendor optics is a bigger issue. There are a number of switch vendors that refuse to support 3rd party optics, even if they are re-branding those same optics. The problem is margins are so high on optics, it is a major cash-cow for most switch vendors. I have had this discussion with switch vendor: they will not budge, giving all kinds of quality/support issues as the reason. It is possible to vote with your wallet, and only buy from vendors that support 3rd party. But at some point you get stuck needing to buy equipment from a vendor that doesn't support 3rd party. It seems to me that optics should be considered like parts for a car. If you want to install 3rd party, go ahead. Don't expect optics support from anybody but the 3rd party. But don't stop me from doing it either. Tim: ___ 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 ?
Hi, On Fri, Oct 02, 2009 at 04:14:56PM +0100, Nick Hilliard wrote: On 02/10/2009 15:27, Justin Shore wrote: Back to your question though, yes UDLD should work fine over MCs. as someone else noted, only for optical transceivers. TX does not support UDLD (which was what the original poster was wondering about). Well, the someone was me, and my routers tell me I have no clue... :-) It seems that this was an older restriction on CatOS boxes, and I never even tried enabling it in more recent IOS versions - and indeed, it *does* work on copper ports in at least SXF13 and SXH3a. Cisco-M-XXI#sh udld g1/2 Interface Gi1/2 --- Port enable administrative configuration setting: Enabled Port enable operational state: Enabled Current bidirectional state: Bidirectional ... Cisco-M-XXI#sh int status Gi1/2 connectedrouted a-full a-1000 10/100/1000BaseT Mmmmh :-) (Not that this would usually be necessary, as GigE T autoneg would notice if the link isn't properly wired) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpoqvN5gERxx.pgp Description: PGP signature ___ 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 ?
I don't believe you can do UDLD on TX (copper) interfaces. Even if you could, the MCs would make this not very useful. Generally speaking... make sure the MC does this for you. :) Brian Johnson Converged Network Engineer (CCNP, ENA) Dickey Rural Networks -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Jeff Fitzwater Sent: Friday, October 02, 2009 8:36 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Will UDLD work with converters ? Is there any issues with running UDLD with TX to Fiber converters at each end of a gig cisco to cisco link? We are just over the distance budget with the 10KM optics. 6500 TX port--- to fiber converter--- 18KM fiber--- to converter--- back to TX port on 3750. We are looking at the converters because the Cisco ZX optics are very expensive and the converters with 30KM optics are much cheaper than the 60 KM ZX optics. Thanks in advance... Jeff Fitzwater OIT Network Systems Princeton University ___ 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] Will UDLD work with converters ?
Nick Hilliard wrote: [100% agreed on rant. ghods, it is so depressing to fork out for cisco optics and find that they don't work on other cisco gear]. Yeah, it's awful. We're looking at ONSs right now and are faced with the penalty (I think that's the appropriate word) of having to spare a completely unique set of GigE optics just for the ONSs. I can understand to a degree Cisco only supporting Cisco optics but not even all of Cisco supports all of Cisco's optics. That's the worst part about it. On 02/10/2009 15:27, Justin Shore wrote: Back to your question though, yes UDLD should work fine over MCs. as someone else noted, only for optical transceivers. TX does not support UDLD (which was what the original poster was wondering about). I saw that as well and that's curious because I'm doing it today on TX interfaces. Been doing it for years and it works great. It's even served it's purpose on one occasion when a 80k single-strand optic in a series of back to back MCs partially failed and was transmitting but not receiving. Locating the 1 bad optic was a PITA but at least it brought the link down so my alternate routing paths picked up the load with minimal loss. 7613-1.clr#sh int gi9/9 capabilities GigabitEthernet9/9 Model: WS-X6748-GE-TX Type: 10/100/1000BaseT Speed: 10,100,1000,auto Duplex:half,full Trunk encap. type: 802.1Q,ISL Trunk mode:on,off,desirable,nonegotiate Channel: yes Broadcast suppression: percentage(0-100) Flowcontrol: rx-(off,on,desired),tx-(off,on,desired) Membership:static Fast Start:yes QOS scheduling:rx-(2q8t), tx-(1p3q8t) CoS rewrite: yes ToS rewrite: yes Inline power: no SPAN: source/destination UDLD yes Link Debounce: yes Link Debounce Time:no Ports on ASIC: 1-12 Port-Security: yes 7613-1.clr#sh udld neighbors Port Device Name Device ID Port IDNeighbor State --- - ----- Gi9/90169D2180B4 1Gi1/1 Bidirectional Gi9/9.40 0169D2180B4 1Gi1/1 Bidirectional 6524-1.brd#sh int gi1/1 capabilities GigabitEthernet1/1 Model: ME-C6524GT-8S Type: 10/100/1000BaseT Speed: 10,100,1000,auto Duplex:half,full Trunk encap. type: 802.1Q,ISL Trunk mode:on,off,desirable,nonegotiate Channel: yes Broadcast suppression: none Flowcontrol: rx-(off,on,desired),tx-(off,on,desired) Membership:static Fast Start:yes QOS scheduling:rx-(1q2t), tx-(1p3q8t) QOS queueing mode: rx-(cos), tx-(cos) CoS rewrite: yes ToS rewrite: yes Inline power: no Inline power policing: no SPAN: source/destination UDLD yes Link Debounce: yes Link Debounce Time:no Ports on ASIC: 1-12 Remote switch uplink: no Dot1x: yes Port-Security: yes 6524-1.brd#sh udld neighbors Port Device Name Device ID Port IDNeighbor State --- - ----- Gi1/1 0187425650 1Gi9/9 Bidirectional Gi1/1.4010 0187425650 1Gi9/9 Bidirectional Perhaps TX UDLD is only available on certain platforms. 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] Will UDLD work with converters ?
Hi, On Fri, Oct 02, 2009 at 11:47:11AM -0500, Justin Shore wrote: understand to a degree Cisco only supporting Cisco optics but not even all of Cisco supports all of Cisco's optics. That's the worst part about it. There's no all of Cisco. There's competing BUs. If you buy switch BU SFPs, the ONS BU won't get money. Can't have that. (The amazing part is that not even the stock market seems to think that this is a good strategy - it *does* increase revenue, though, until enough customers are annoyed enough to find other vendors) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpD0cxcxscaH.pgp Description: PGP signature ___ 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 ?
On Fri, Oct 2, 2009 at 7:27 AM, Justin Shore jus...@justinshore.com wrote: The single-strand Cisco GigE optic is limited to 10km too. Single-strand optics are critical in the SP world. Not everyone has excess bundles of dark fiber to play with to turn up a simple GigE link. I understand that Cisco wouldn't sell a lot of these since most of their business is enterprise. I get that. I get that too, but I strongly disagree with the strategy. In this part of the world (Whatcom/Skagit county, Washington state), dark fiber is cheap and readily available for about the cost of a T1 in many locations. (If buildout is required, it's often subsidized into the MRC.) My network at $dayjob is hardly big enough to be considered enterprise (our fanciest piece of kit is a 3560), yet for branch locations we still have the need to use unsupported 70km and single-strand optics. Surely the world has other communities like this, with cheap plentiful fiber? $4k for a ZX transceiver with the right logo on it is laughable. -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] Will UDLD work with converters ?
nick hatch wrote: I get that too, but I strongly disagree with the strategy. In this part of the world (Whatcom/Skagit county, Washington state), dark fiber is cheap and readily available for about the cost of a T1 in many locations. (If buildout is required, it's often subsidized into the MRC.) Unfortunately where I'm at in the Midwest there is no dark fiber to be had. None of the large local LECs are willing to even carry a wavelength for a customer. There simply isn't anyone in the areas that I'm located to in offering wavelengths or dark fiber as a product to force the other players to compete. Now in KC, Denver, Lincoln or OKC it's different story. There are enough people willing to do it there that the other LECs have all fallen into step and also offer the service. Many are the very same LECs that refuse to do so here. My network at $dayjob is hardly big enough to be considered enterprise (our fanciest piece of kit is a 3560), yet for branch locations we still have the need to use unsupported 70km and single-strand optics. I'd love to have the potential to lease dark fiber like that. It would make my life much easier. Surely the world has other communities like this, with cheap plentiful fiber? $4k for a ZX transceiver with the right logo on it is laughable. It depends on the market but it's not available everywhere. Forbes rated a city 15m away from our HQ (and one of the towns we CLECed) in the top 10 of IT meccas in the US and yet it's still not possible there. Go figure. The state independent telcos are working together to build a state fiber network to provide low-cost transport across the state, like what they did in Indiana and Texas. It's a few years out though. 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/
[c-nsp] EnableLocalLAN don't work
Hello, I have a cisco 871 as VPN end-point. I need to access my local lan, when my vpn is up. I'm using vpn-client 5.0.01.0600 for Windows on XP. I tried to enable Allow local lan access but that don't work much. I found that I need to enable split tunneling. I found doc to do that on vpn concentretor or pix, but I did not found anything for simple routers. Any idea ? EnableLocalLAN=0 ; This allows the user to access the local LAN if it is set to 1. ; Otherwise, the user cannot access the local LAN segment while a ; VPN session is up (the group must also be set up for split ; tunneling to allow local LAN access) ___ 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] EnableLocalLAN don't work
Hello Julien: -Original Message- From: [EMAIL PROTECTED] [mailto:cisco-nsp- [EMAIL PROTECTED] On Behalf Of julien leroiso Sent: Friday, June 06, 2008 7:19 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] EnableLocalLAN don't work Hello, I have a cisco 871 as VPN end-point. I need to access my local lan, when my vpn is up. I'm using vpn-client 5.0.01.0600 for Windows on XP. I tried to enable Allow local lan access but that don't work much. I found that I need to enable split tunneling. I found doc to do that on vpn concentretor or pix, but I did not found anything for simple routers. Any idea ? crypto isakmp client configuration group GROUPNAME various other entries acl ACL NUMBER (150 in the example below) So, let's say your local lan behind the router is 192.168.1.0/24 and your Pool range is 192.168.2.0/24, your acl would be: access-list 150 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 So, any traffic from 192.168.2.0/24 not going to 192.168.1.0/24 will go out the split-tunnel. Regards, Mike PGP.sig Description: PGP signature ___ 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/
