Re: [c-nsp] Non Cisco SFP
On Feb 2, 2015, at 11:28 AM, Charles Sprickman sp...@bway.net wrote: On Feb 2, 2015, at 2:19 PM, Mark Tinka mark.ti...@seacom.mu wrote: On 2/Feb/15 18:46, Warren Jackson wrote: Sure, no problem! 1) Lack of Cisco support. You will find yourself behind the eight-ball dealing with the TAC if you have these in your chassis. Sounds like a small deal, but I for one don't have the time to deal with it. I've found this not to be an issue in practice. And if it is, it’s solved with a handful of spares per location. If you have 100 SFPs at one location and you’re saving a few hundred per SFP, keeping a few “genuine” units is a small price if you have TAC paranoia. …or if you just need to be able to rule that out as an issue. We do that, have one each of the Cisco-branded units on hand. -Bill signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] Non Cisco SFP
On 02/02/2015 16:46, Warren Jackson wrote: 1) Lack of Cisco support. You will find yourself behind the eight-ball dealing with the TAC if you have these in your chassis. Sounds like a small deal, but I for one don't have the time to deal with it. You won't run into problems like this unless you have an issue which can specifically be directly pinned down to a transceiver, in which case you you can pull out the single OEM cold spare that you need for situations like this. 2) Cost. If you buy through a Cisco gold provider then you are going to get a good price on the optics No, you just won't. You'll be ripped off, consistently and shamelessly. enough to where the difference pays off in support We're talking about transceivers here. If one fails, you throw it away and replace it with a new unit from your set of cold spares. It's simply not worth the hassle going through RMA for something like this. as these can been wrapped in through your smartnet converage. If you have optics from another vendor you are dealing with their support and Cisco support, keeps things simple. Makes it worth paying the bit extra you would pay. We aren't talking about thousands of dollars difference in price here. Thousands of dollars per unit sounds about right and if you're buying transceivers in quantity, thousands of dollars per unit turns into real money pretty quickly. My staple transceiver these days is 10G LR SFP+. You can buy reliable, supported third party SFP-10G-LR compatible units for around €100. Cisco charges $4000 list: SFP-10G-LR= 10GBASE-LR SFP Module D $3,995.00 Are you getting 97% discount from Cisco? If not, you're being fleeced. 3) Who? Which SFP manufacturer(s) would you recommend besides Cisco? I buy from Flexoptix: they provide an enormous range of third party transceivers and a transceiver reprogrammer which is incredibly easy to use. Everything is done online; delivery is extremely fast and efficient, and we rarely experience transceiver failures. In every respect, it's a complete pleasure to deal with them as suppliers. 4) Several of the Cisco SFP's provide the show tranceiver telemetry that aid in troubeshooting the physical layer, which you won't get with the off-market brand tranceivers. as others have pointed out, this is factually incorrect from many points of view. 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] MPLS LDP Sync w/ ISIS over point to point Link
With this new site, I only planed on only bringing up the isis adjacency as it is a new site and no OSPF is required (because I don't need to migrate anything off). However the ISIS adjacency won't come up because it doesn't have an LDP session up yet. And the LDP session wont come up without the IGP coming up. Why would a regular (non-targeted) LDP session using the local link subnet need IGP to establish a session? Your routing-table already contains the connected route from that interface. ___ 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] MPLS LDP Sync w/ ISIS over point to point Link
Hey I've been rolling out new routers to various sites throughout our organisation. And in doing so, I've been applying the mpls ldp sync command under the router isis subsection. This has been fine up until now. Because all other sites are running OSPF and ISIS together (as we are in the process of migrating away from an OSPF network to an ISIS based MPLS core network, etc). With this new site, I only planed on only bringing up the isis adjacency as it is a new site and no OSPF is required (because I don't need to migrate anything off). However the ISIS adjacency won't come up because it doesn't have an LDP session up yet. And the LDP session wont come up without the IGP coming up. This is some real chicken and egg stuff right here. It has become quiet clear that all my other routers in production which have LDP sessions are essentially relying on that OSPF adjacency to help form the initial LDP session. One day I plan to shut those down. Which could cause me big issues further down the road. I do have ldp session protection enabled ... but if a router was to reboot and have no ospf to help form the initial LDP, then it seems my isis adjecencie may never form. That is the worst case scenario Getting back to my point ... If I remove the mpls ldp sync on both routers the ISIS adjacency forms immediately. So this is definitely the culprit. How on earth is this feature supposed to work in a production environment? Am I missing something here? Am I supposed to manually form ldp sessions (targeted) or something? If anyone has experience with this, I'm all ears. Kind Regards Troy ___ 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 6500 SUP720-3BXL upgrade to 15.1.2.SY4a question
Apparently didn't send the correct link (release notes will take you here). http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/28724-161.html On Mon, Feb 2, 2015 at 10:51 AM, George Peek gp...@ucsc.edu wrote: They are independent of each other and not required for the upgrade to 15.x (in most cases just s72033-advipservicesk9-mz.151-2.SY4a.bin will do). I wouldn't be too surprised if these are the latest versions you found. Now that being said, I don't know what you are currently running so it may be a requirement. I would start here (notice determine what bootrom version you require to upgrade, etc). https://software.cisco.com/download/release.html?mdfid=280829702flowid=20153softwareid=280805680release=15.1.2-SY4arelind=AVAILABLErellifecycle=MDreltype=latest On Fri, Jan 30, 2015 at 8:55 AM, Erik Sundberg esundb...@nitelusa.com wrote: Looking to upgrade a couple of our 6500 SUP720-3BXL to 15.1.2SY4a. We have the WS-6748-GE-TX and WS-6724-SFP Cards installed, no SIP/SPA installed. Just want to make sure the following associated software is correct. The software version numbers make you questions yourself because the IOS version is 15.1.2 and the boot image is 12.2.33SXI and so on. Boot Image: s72033-boot-mz.122-33.SXI14.bin RP ROMMON: c6msfc3-rm2.srec.122-17r.SX7 SP ROMMON: c6ksup720-rm2.srec.8-5-4.srec IOS: s72033-advipservicesk9-mz.151-2.SY4a.bin Thanks Erik CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank 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/ ___ 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] Non Cisco SFP
Den 02.02.2015 17:46, skrev Warren Jackson: Sure, no problem! 1) Lack of Cisco support. You will find yourself behind the eight-ball dealing with the TAC if you have these in your chassis. Sounds like a small deal, but I for one don't have the time to deal with it. Cisco do actually have a policy around use of third party components in their equipment: http://www.cisco.com/c/en/us/products/prod_warranty09186a00800b5594.html I find this reasonable. It makes me confident to keep buying third party SFP's and still expect Cisco to give me support in most cases. -- Hans Kristian Eiken ___ 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] MPLS LDP Sync w/ ISIS over point to point Link
Are you doing ldp sourced from loopback or something? -Blake On Mon, Feb 2, 2015 at 1:26 PM, Troy Boutso sensible...@gmail.com wrote: Hey I've been rolling out new routers to various sites throughout our organisation. And in doing so, I've been applying the mpls ldp sync command under the router isis subsection. This has been fine up until now. Because all other sites are running OSPF and ISIS together (as we are in the process of migrating away from an OSPF network to an ISIS based MPLS core network, etc). With this new site, I only planed on only bringing up the isis adjacency as it is a new site and no OSPF is required (because I don't need to migrate anything off). However the ISIS adjacency won't come up because it doesn't have an LDP session up yet. And the LDP session wont come up without the IGP coming up. This is some real chicken and egg stuff right here. It has become quiet clear that all my other routers in production which have LDP sessions are essentially relying on that OSPF adjacency to help form the initial LDP session. One day I plan to shut those down. Which could cause me big issues further down the road. I do have ldp session protection enabled ... but if a router was to reboot and have no ospf to help form the initial LDP, then it seems my isis adjecencie may never form. That is the worst case scenario Getting back to my point ... If I remove the mpls ldp sync on both routers the ISIS adjacency forms immediately. So this is definitely the culprit. How on earth is this feature supposed to work in a production environment? Am I missing something here? Am I supposed to manually form ldp sessions (targeted) or something? If anyone has experience with this, I'm all ears. Kind Regards Troy ___ 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] MPLS LDP Sync w/ ISIS over point to point Link
Without going too deep right now as I am outside I think mpls ldp igp sync holddown sec should fix the problem . On Monday, February 2, 2015, Troy Boutso sensible...@gmail.com wrote: Hey I've been rolling out new routers to various sites throughout our organisation. And in doing so, I've been applying the mpls ldp sync command under the router isis subsection. This has been fine up until now. Because all other sites are running OSPF and ISIS together (as we are in the process of migrating away from an OSPF network to an ISIS based MPLS core network, etc). With this new site, I only planed on only bringing up the isis adjacency as it is a new site and no OSPF is required (because I don't need to migrate anything off). However the ISIS adjacency won't come up because it doesn't have an LDP session up yet. And the LDP session wont come up without the IGP coming up. This is some real chicken and egg stuff right here. It has become quiet clear that all my other routers in production which have LDP sessions are essentially relying on that OSPF adjacency to help form the initial LDP session. One day I plan to shut those down. Which could cause me big issues further down the road. I do have ldp session protection enabled ... but if a router was to reboot and have no ospf to help form the initial LDP, then it seems my isis adjecencie may never form. That is the worst case scenario Getting back to my point ... If I remove the mpls ldp sync on both routers the ISIS adjacency forms immediately. So this is definitely the culprit. How on earth is this feature supposed to work in a production environment? Am I missing something here? Am I supposed to manually form ldp sessions (targeted) or something? If anyone has experience with this, I'm all ears. Kind Regards Troy ___ cisco-nsp mailing list cisco-nsp@puck.nether.net javascript:; https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Sent from iPhone ___ 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] Non Cisco SFP
On 02/02/2015 12:02, Warren Jackson wrote: Highly recommend you do not use this in production. Disagree, strongly. Vendor transceivers are racket, a scam, hugely inflated and price, and the practice of transceiver locking is enormously anti-competitive, not to mention operationally tedious. I recommend people buy transceivers from good 3rd party vendors, and tell the equipment vendors to take a hike with their vendor parts. ___ 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] Enabling multicast routing on 3750G platform
Yes it was all on one switch to simulate an environment where a stack of 3750s services multiple floors in a building for streaming a TV. On Mon, Feb 2, 2015 at 7:05 AM, Warren Jackson wrjack1...@gmail.com wrote: And this is all on one switch? On Fri, Jan 30, 2015 at 6:12 PM Adam Vitkovsky avitkov...@gammatelecom.com wrote: Well there are actually two versions of the cmd. ip igmp static-group - Is used widely in contribution video setups where there's no PIM/IGMP between the two providers. Or in 3play setups to speed up channel selection you statically join all the channels on the DR for the L2 segment. Or basically anytime where you always want the streams to be received and you don't want to or can't rely on the IGMP membership reports (e.g. backup). ip igmp join-group - though it achieves the same thing as the above cmd it makes the router to actually listen to the m-cast stream that is beneficial when you want to test multicast with ping to the group address for example -the router (or routers) which joined the group will be listed as replies to each ping -that's how you know the multicast was delivered to them successfully adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Lobo Sent: 30 January 2015 02:00 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Enabling multicast routing on 3750G platform Problem solved! You guys were right about VLC and its TTL. Turns out there's a bug in the program where changing the TTL in the GUI doesn't affect streaming for some reason. I added a ttl=30 to the string and the stream started flowing to the secondary port. I even changed things back to vlans and it routed perfectly fine. I have a question about one comment that was made regarding the igmp- join command. In all the documentation I've read, it says to put that command on the interfaces that plan on receiving the stream(s). Some comments suggested removing it or not needing it and with my own testing it clearly works fine even without this command. Why is that? This is the final show ip mroute: Switch#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group V - RD Vector, v - Vector Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.255.255.250), 02:45:34/00:02:34, RP 3.3.3.3, flags: SJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Vlan100, Forward/Sparse, 00:00:38/00:02:34 Vlan200, Forward/Sparse, 02:42:59/00:02:32 (*, 239.0.0.1), 02:45:35/stopped, RP 3.3.3.3, flags: SJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Vlan200, Forward/Sparse, 02:42:15/00:02:33 (1.1.1.1, 239.0.0.1), 00:00:40/00:02:58, flags: JT Incoming interface: Vlan100, RPF nbr 0.0.0.0 Outgoing interface list: Vlan200, Forward/Sparse, 00:00:40/00:02:33 (*, 224.0.1.40), 02:45:35/00:02:28, RP 3.3.3.3, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Loopback0, Forward/Sparse, 02:45:36/00:02:27 Switch# Thanks again for the tips everyone! Jose On Thu, Jan 29, 2015 at 7:23 AM, Adam Vitkovsky avitkov...@gammatelecom.com wrote: Hi Lobo, Ok so the SW is indeed a DR on port GigabitEthernet1/0/1 and it's obviously receiving some stream in which case it should create an (s,g) state and send a register msg to the RP and RP should update its group cache (all should be done internally since the DR=RP). However none of this is happening most likely because the switch doesn't like something about the stream (destination mac address, ttl, som security feature,..). Can you do: debug ip pim -to see if it shows why the switch ignores the incoming stream. -or some other techniques to see why the incoming multicast frames are being dropped silently. adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Lobo Sent: 29 January 2015 00:57 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Enabling multicast routing on 3750G platform I've moved the configuration on the switch so that the ports are routed now instead of using vlans but still no go. Here is the output from a show ip mroute: Switch#sh ip mroute IP Multicast
Re: [c-nsp] Non Cisco SFP
On 2/Feb/15 13:23, Harry Hambi - Atos wrote: Hi all , I have a non-cisco SFP can someone remind me of the command to run in order to use the SFP in a cisco chassis. Is the command a hidden command?, do you need to run in interface config mode?, will the switch require a reboot?. Thanks in advance service unsupported-transceiver Mark. ___ 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] Non Cisco SFP
Thanks Rgds Harry Harry Hambi BEng(Hons) MIET Rsgb -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Warren Jackson Sent: 02 February 2015 12:03 To: Mark Tinka; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Non Cisco SFP Highly recommend you do not use this in production. On Mon, Feb 2, 2015 at 6:50 AM Mark Tinka mark.ti...@seacom.mu wrote: On 2/Feb/15 13:23, Harry Hambi - Atos wrote: Hi all , I have a non-cisco SFP can someone remind me of the command to run in order to use the SFP in a cisco chassis. Is the command a hidden command?, do you need to run in interface config mode?, will the switch require a reboot?. Thanks in advance service unsupported-transceiver Mark. ___ 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] Non Cisco SFP
On 2/Feb/15 14:02, Warren Jackson wrote: Highly recommend you do not use this in production. Because? We do, no issues. Mark. ___ 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] Non Cisco SFP
On 02/02/2015 12:35, Phil Mayers wrote: hugely inflated and price s/and/in/ Sigh ;o) ___ 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] Enabling multicast routing on 3750G platform
And this is all on one switch? On Fri, Jan 30, 2015 at 6:12 PM Adam Vitkovsky avitkov...@gammatelecom.com wrote: Well there are actually two versions of the cmd. ip igmp static-group - Is used widely in contribution video setups where there's no PIM/IGMP between the two providers. Or in 3play setups to speed up channel selection you statically join all the channels on the DR for the L2 segment. Or basically anytime where you always want the streams to be received and you don't want to or can't rely on the IGMP membership reports (e.g. backup). ip igmp join-group - though it achieves the same thing as the above cmd it makes the router to actually listen to the m-cast stream that is beneficial when you want to test multicast with ping to the group address for example -the router (or routers) which joined the group will be listed as replies to each ping -that's how you know the multicast was delivered to them successfully adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Lobo Sent: 30 January 2015 02:00 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Enabling multicast routing on 3750G platform Problem solved! You guys were right about VLC and its TTL. Turns out there's a bug in the program where changing the TTL in the GUI doesn't affect streaming for some reason. I added a ttl=30 to the string and the stream started flowing to the secondary port. I even changed things back to vlans and it routed perfectly fine. I have a question about one comment that was made regarding the igmp- join command. In all the documentation I've read, it says to put that command on the interfaces that plan on receiving the stream(s). Some comments suggested removing it or not needing it and with my own testing it clearly works fine even without this command. Why is that? This is the final show ip mroute: Switch#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group V - RD Vector, v - Vector Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.255.255.250), 02:45:34/00:02:34, RP 3.3.3.3, flags: SJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Vlan100, Forward/Sparse, 00:00:38/00:02:34 Vlan200, Forward/Sparse, 02:42:59/00:02:32 (*, 239.0.0.1), 02:45:35/stopped, RP 3.3.3.3, flags: SJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Vlan200, Forward/Sparse, 02:42:15/00:02:33 (1.1.1.1, 239.0.0.1), 00:00:40/00:02:58, flags: JT Incoming interface: Vlan100, RPF nbr 0.0.0.0 Outgoing interface list: Vlan200, Forward/Sparse, 00:00:40/00:02:33 (*, 224.0.1.40), 02:45:35/00:02:28, RP 3.3.3.3, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Loopback0, Forward/Sparse, 02:45:36/00:02:27 Switch# Thanks again for the tips everyone! Jose On Thu, Jan 29, 2015 at 7:23 AM, Adam Vitkovsky avitkov...@gammatelecom.com wrote: Hi Lobo, Ok so the SW is indeed a DR on port GigabitEthernet1/0/1 and it's obviously receiving some stream in which case it should create an (s,g) state and send a register msg to the RP and RP should update its group cache (all should be done internally since the DR=RP). However none of this is happening most likely because the switch doesn't like something about the stream (destination mac address, ttl, som security feature,..). Can you do: debug ip pim -to see if it shows why the switch ignores the incoming stream. -or some other techniques to see why the incoming multicast frames are being dropped silently. adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Lobo Sent: 29 January 2015 00:57 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Enabling multicast routing on 3750G platform I've moved the configuration on the switch so that the ports are routed now instead of using vlans but still no go. Here is the output from a show ip mroute: Switch#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X
[c-nsp] Non Cisco SFP
Hi all , I have a non-cisco SFP can someone remind me of the command to run in order to use the SFP in a cisco chassis. Is the command a hidden command?, do you need to run in interface config mode?, will the switch require a reboot?. Thanks in advance Rgds Harry Harry Hambi BEng(Hons) MIET Rsgb ___ 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] Non Cisco SFP
And why is that? We have many non-cisco optics deployed without trouble. I would avoid the cheapest-of-the-cheap optics, as those have been rumored to have trouble, slow i2c responses, or other issues that the software is poorly coded to handle. We’ve done this with SFP, XFP, SFP+ and CFP without issues. Do you have details of what your issues were Warren? I’ve had more issues with Cisco optics in Cisco than non-Cisco optics in Cisco. - jared On Feb 2, 2015, at 7:02 AM, Warren Jackson wrjack1...@gmail.com wrote: Highly recommend you do not use this in production. On Mon, Feb 2, 2015 at 6:50 AM Mark Tinka mark.ti...@seacom.mu wrote: On 2/Feb/15 13:23, Harry Hambi - Atos wrote: Hi all , I have a non-cisco SFP can someone remind me of the command to run in order to use the SFP in a cisco chassis. Is the command a hidden command?, do you need to run in interface config mode?, will the switch require a reboot?. Thanks in advance service unsupported-transceiver Mark. ___ 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] Non Cisco SFP
Highly recommend you do not use this in production. On Mon, Feb 2, 2015 at 6:50 AM Mark Tinka mark.ti...@seacom.mu wrote: On 2/Feb/15 13:23, Harry Hambi - Atos wrote: Hi all , I have a non-cisco SFP can someone remind me of the command to run in order to use the SFP in a cisco chassis. Is the command a hidden command?, do you need to run in interface config mode?, will the switch require a reboot?. Thanks in advance service unsupported-transceiver Mark. ___ 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] BGP/route-map/acl question/logic...
Hi Everyone, If I want to block certain prefixes from an upstream, and accept the rest and then tag the accepted prefixes, which is the correct method..I *thought* the first one was correct, but it doesnt do what I expected...i.e. the ACL gets a hit on deny 10.0.0.0/24, but it is still allowed(i.e We still receive the prefix)?: route-map UPSTREAM_A_IN permit 10 match ip address 98 continue 20 route-map UPSTREAM_A_IN permit 20 set community 12345:1 access-list 98 deny 10.0.0.0 0.255.255.255 access-list 98 permit any or...(I havent tested this one yet): route-map UPSTREAM_A_IN deny 10 match ip address 98 continue 20 route-map UPSTREAM_A_IN permit 20 set community 12345:1 access-list 98 permit 10.0.0.0 0.255.255.255 Cheers. ___ 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] Non Cisco SFP
I am glad to see this thread, we are on the cusp of making the plunge into aftermarket optics and have been looking for anything to tip the scale one way or the other. I had a chat with a Gartner fellow a couple of weeks ago and the outcome of that call did not tip the scales for me. This thread is providing me with great information - thanks! We are also looking at aftermarket DAC or Twinax cables, what has been your experience with those in a Cisco environment? We have had a couple dozen Dell DAC's connecting Dell servers to HP 5900's with good success but have not tried any in our Nexus environment. Thanks! Rick Martin Network Architect State of Arkansas, Department of Information Systems (501) 682-4037 -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers Sent: Monday, February 02, 2015 6:36 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Non Cisco SFP On 02/02/2015 12:02, Warren Jackson wrote: Highly recommend you do not use this in production. Disagree, strongly. Vendor transceivers are racket, a scam, hugely inflated and price, and the practice of transceiver locking is enormously anti-competitive, not to mention operationally tedious. I recommend people buy transceivers from good 3rd party vendors, and tell the equipment vendors to take a hike with their vendor parts. ___ 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] BGP/route-map/acl question/logic...
Hi, if you want to deny the prefix you have to use deny ;) The untested version of your route-map should do the expected, but you don't need the continue 20 as the continue doesn't work with a deny. Karsten Am 03.02.2015 06:21, schrieb CiscoNSP List: Hi Everyone, If I want to block certain prefixes from an upstream, and accept the rest and then tag the accepted prefixes, which is the correct method..I *thought* the first one was correct, but it doesnt do what I expected...i.e. the ACL gets a hit on deny 10.0.0.0/24, but it is still allowed(i.e We still receive the prefix)?: route-map UPSTREAM_A_IN permit 10 match ip address 98 continue 20 route-map UPSTREAM_A_IN permit 20 set community 12345:1 access-list 98 deny 10.0.0.0 0.255.255.255 access-list 98 permit any or...(I havent tested this one yet): route-map UPSTREAM_A_IN deny 10 match ip address 98 continue 20 route-map UPSTREAM_A_IN permit 20 set community 12345:1 access-list 98 permit 10.0.0.0 0.255.255.255 Cheers. ___ 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] BGP/route-map/acl question/logic...
route-map UPSTREAM_A_IN permit 10 match ip address 98 I would strongly suggest to use prefix-lists instead of access-lists, they are made on purpose to match prefixes, are a lot easier to use and provide much more flexibility. ___ 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] Non Cisco SFP
Hi, On Mon, Feb 02, 2015 at 03:29:41PM +, Rick Martin wrote: I am glad to see this thread, we are on the cusp of making the plunge into aftermarket optics Whatever aftermarket optics are - I would not go and by *used* optics, because that's about the only thing in modern hardware that truly ages, aka optics burn out over time. 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 pgpXUcjHrK5pR.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] Non Cisco SFP
On Feb 2, 2015, at 11:16 AM, Gert Doering g...@greenie.muc.de wrote: Hi, On Mon, Feb 02, 2015 at 03:29:41PM +, Rick Martin wrote: I am glad to see this thread, we are on the cusp of making the plunge into aftermarket optics Whatever aftermarket optics are - I would not go and by *used* optics, because that's about the only thing in modern hardware that truly ages, aka optics burn out over time. Agreed, general use optics shouldn’t cost you more than $300, and that is being quite generous. If you wanted to program your own optics, apparently you can get one of these new raspberry pis: http://eoinpk.blogspot.com/2014/05/raspberry-pi-and-programming-eeproms-on.html It includes a link at the bottom for how to program the optics to be ‘cisco compatible’. - Jared ___ 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] Non Cisco SFP
This is exactly the opposite of my experience. The Cisco branded optics are generally the problem supporting dom properly, or have interoperability issues in their own gear, while the generics + a programmer are generally more reliable, far cheaper, and far more usable across the different platforms due to the Cisco attempts at DRM for a standardized interface. -Blake On Mon, Feb 2, 2015 at 8:46 AM, Warren Jackson wrjack1...@gmail.com wrote: Sure, no problem! 1) Lack of Cisco support. You will find yourself behind the eight-ball dealing with the TAC if you have these in your chassis. Sounds like a small deal, but I for one don't have the time to deal with it. 2) Cost. If you buy through a Cisco gold provider then you are going to get a good price on the optics, enough to where the difference pays off in support, as these can been wrapped in through your smartnet converage. If you have optics from another vendor you are dealing with their support and Cisco support, keeps things simple. Makes it worth paying the bit extra you would pay. We aren't talking about thousands of dollars difference in price here. 3) Who? Which SFP manufacturer(s) would you recommend besides Cisco? 4) Several of the Cisco SFP's provide the show tranceiver telemetry that aid in troubeshooting the physical layer, which you won't get with the off-market brand tranceivers. Just my 2 cents based on my experience. How about the rest of you guys? -Warjack On Mon Feb 02 2015 at 11:37:59 AM Jared Mauch ja...@puck.nether.net wrote: On Feb 2, 2015, at 11:16 AM, Gert Doering g...@greenie.muc.de wrote: Hi, On Mon, Feb 02, 2015 at 03:29:41PM +, Rick Martin wrote: I am glad to see this thread, we are on the cusp of making the plunge into aftermarket optics Whatever aftermarket optics are - I would not go and by *used* optics, because that's about the only thing in modern hardware that truly ages, aka optics burn out over time. Agreed, general use optics shouldn’t cost you more than $300, and that is being quite generous. If you wanted to program your own optics, apparently you can get one of these new raspberry pis: http://eoinpk.blogspot.com/2014/05/raspberry-pi-and- programming-eeproms-on.html It includes a link at the bottom for how to program the optics to be ‘cisco compatible’. - Jared ___ 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] Non Cisco SFP
Agreed. We have all sorts of third party brand SFPs around here. 1G and 10G. You can buy both DOM capable or not. We've not had any problems out of them. Actually, this morning we swapped out an optic that died over night. It was a Cisco branded one. :) -Christopher On 2/2/15, 12:56 PM, Jared Mauch ja...@puck.nether.net wrote: On Feb 2, 2015, at 11:46 AM, Warren Jackson wrjack1...@gmail.com wrote: Sure, no problem! 1) Lack of Cisco support. You will find yourself behind the eight-ball dealing with the TAC if you have these in your chassis. Sounds like a small deal, but I for one don't have the time to deal with it. Sounds like you work for Cisco or were properly ingrained in their marketing thinking. 2) Cost. If you buy through a Cisco gold provider then you are going to get a good price on the optics, enough to where the difference pays off in support, as these can been wrapped in through your smartnet converage. If you have optics from another vendor you are dealing with their support and Cisco support, keeps things simple. Makes it worth paying the bit extra you would pay. We aren't talking about thousands of dollars difference in price here. Not really. 3) Who? Which SFP manufacturer(s) would you recommend besides Cisco? Finisar (for examples). 4) Several of the Cisco SFP's provide the show tranceiver telemetry that aid in troubeshooting the physical layer, which you won't get with the off-market brand tranceivers. Actually, not true, this is the problem I have with their first party optics. We¹ve met with their TMG group several times and have outstanding software defects that are unresolved. Just my 2 cents based on my experience. How about the rest of you guys? We¹ve had great luck with 3rd party and better support for DOM than their first party optics. - Jared -Warjack On Mon Feb 02 2015 at 11:37:59 AM Jared Mauch ja...@puck.nether.net wrote: On Feb 2, 2015, at 11:16 AM, Gert Doering g...@greenie.muc.de wrote: Hi, On Mon, Feb 02, 2015 at 03:29:41PM +, Rick Martin wrote: I am glad to see this thread, we are on the cusp of making the plunge into aftermarket optics Whatever aftermarket optics are - I would not go and by *used* optics, because that's about the only thing in modern hardware that truly ages, aka optics burn out over time. Agreed, general use optics shouldn¹t cost you more than $300, and that is being quite generous. If you wanted to program your own optics, apparently you can get one of these new raspberry pis: http://eoinpk.blogspot.com/2014/05/raspberry-pi-and-programming-eeproms-o n.html It includes a link at the bottom for how to program the optics to be Œcisco compatible¹. - Jared ___ 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] Cisco 6500 SUP720-3BXL upgrade to 15.1.2.SY4a question
They are independent of each other and not required for the upgrade to 15.x (in most cases just s72033-advipservicesk9-mz.151-2.SY4a.bin will do). I wouldn't be too surprised if these are the latest versions you found. Now that being said, I don't know what you are currently running so it may be a requirement. I would start here (notice determine what bootrom version you require to upgrade, etc). https://software.cisco.com/download/release.html?mdfid=280829702flowid=20153softwareid=280805680release=15.1.2-SY4arelind=AVAILABLErellifecycle=MDreltype=latest On Fri, Jan 30, 2015 at 8:55 AM, Erik Sundberg esundb...@nitelusa.com wrote: Looking to upgrade a couple of our 6500 SUP720-3BXL to 15.1.2SY4a. We have the WS-6748-GE-TX and WS-6724-SFP Cards installed, no SIP/SPA installed. Just want to make sure the following associated software is correct. The software version numbers make you questions yourself because the IOS version is 15.1.2 and the boot image is 12.2.33SXI and so on. Boot Image: s72033-boot-mz.122-33.SXI14.bin RP ROMMON: c6msfc3-rm2.srec.122-17r.SX7 SP ROMMON: c6ksup720-rm2.srec.8-5-4.srec IOS: s72033-advipservicesk9-mz.151-2.SY4a.bin Thanks Erik CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank 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/ ___ 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] Non Cisco SFP
I was offering something for the super-geeks :) at $dayjob we purchase from champion one, but have also tested other optics from OSI hardware and others. I’ve even heard of good luck from fiberstore.com as well, which is super-cheap. - Jared On Feb 2, 2015, at 11:46 AM, Matthew Crocker matt...@corp.crocker.com wrote: You could buy http://www.flexoptix.net/en/flexbox-v3-transceiver-programmer.html and save the rPi headaches. I haven’t used this but it does look interesting. Or, you could just go here: http://approvedoptics.com/ Cisco, Juniper every SFP, XFP, SFP+ i’ve ordered has worked 100% and they are priced right. -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matt...@crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com On Feb 2, 2015, at 11:31 AM, Jared Mauch ja...@puck.nether.net wrote: On Feb 2, 2015, at 11:16 AM, Gert Doering g...@greenie.muc.de wrote: Hi, On Mon, Feb 02, 2015 at 03:29:41PM +, Rick Martin wrote: I am glad to see this thread, we are on the cusp of making the plunge into aftermarket optics Whatever aftermarket optics are - I would not go and by *used* optics, because that's about the only thing in modern hardware that truly ages, aka optics burn out over time. Agreed, general use optics shouldn’t cost you more than $300, and that is being quite generous. If you wanted to program your own optics, apparently you can get one of these new raspberry pis: http://eoinpk.blogspot.com/2014/05/raspberry-pi-and-programming-eeproms-on.html It includes a link at the bottom for how to program the optics to be ‘cisco compatible’. - Jared ___ 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] Non Cisco SFP
On Mon, 2 Feb 2015, Warren Jackson wrote: Sure, no problem! 2) Cost. If you buy through a Cisco gold provider then you are going to get a good price on the optics, enough to where the difference pays off in support, as these can been wrapped in through your smartnet converage. If you have optics from another vendor you are dealing with their support and Cisco support, keeps things simple. Makes it worth paying the bit extra you would pay. We aren't talking about thousands of dollars difference in price here. The difference in 10G optic costs can be substantial. 3) Who? Which SFP manufacturer(s) would you recommend besides Cisco? As far as I know, Cisco doesn't spin their own optics. They usually buy from someone like Finisar and either burn a Cisco vendor ID on them, or have the manufacturer do this as part of their contract. 4) Several of the Cisco SFP's provide the show tranceiver telemetry that aid in troubeshooting the physical layer, which you won't get with the off-market brand tranceivers. Unless those transceivers support DOM. jms ___ 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] Non Cisco SFP
You could buy http://www.flexoptix.net/en/flexbox-v3-transceiver-programmer.html and save the rPi headaches. I haven’t used this but it does look interesting. Or, you could just go here: http://approvedoptics.com/ Cisco, Juniper every SFP, XFP, SFP+ i’ve ordered has worked 100% and they are priced right. -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matt...@crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com On Feb 2, 2015, at 11:31 AM, Jared Mauch ja...@puck.nether.net wrote: On Feb 2, 2015, at 11:16 AM, Gert Doering g...@greenie.muc.de wrote: Hi, On Mon, Feb 02, 2015 at 03:29:41PM +, Rick Martin wrote: I am glad to see this thread, we are on the cusp of making the plunge into aftermarket optics Whatever aftermarket optics are - I would not go and by *used* optics, because that's about the only thing in modern hardware that truly ages, aka optics burn out over time. Agreed, general use optics shouldn’t cost you more than $300, and that is being quite generous. If you wanted to program your own optics, apparently you can get one of these new raspberry pis: http://eoinpk.blogspot.com/2014/05/raspberry-pi-and-programming-eeproms-on.html It includes a link at the bottom for how to program the optics to be ‘cisco compatible’. - Jared ___ 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] Non Cisco SFP
Sure, no problem! 1) Lack of Cisco support. You will find yourself behind the eight-ball dealing with the TAC if you have these in your chassis. Sounds like a small deal, but I for one don't have the time to deal with it. 2) Cost. If you buy through a Cisco gold provider then you are going to get a good price on the optics, enough to where the difference pays off in support, as these can been wrapped in through your smartnet converage. If you have optics from another vendor you are dealing with their support and Cisco support, keeps things simple. Makes it worth paying the bit extra you would pay. We aren't talking about thousands of dollars difference in price here. 3) Who? Which SFP manufacturer(s) would you recommend besides Cisco? 4) Several of the Cisco SFP's provide the show tranceiver telemetry that aid in troubeshooting the physical layer, which you won't get with the off-market brand tranceivers. Just my 2 cents based on my experience. How about the rest of you guys? -Warjack On Mon Feb 02 2015 at 11:37:59 AM Jared Mauch ja...@puck.nether.net wrote: On Feb 2, 2015, at 11:16 AM, Gert Doering g...@greenie.muc.de wrote: Hi, On Mon, Feb 02, 2015 at 03:29:41PM +, Rick Martin wrote: I am glad to see this thread, we are on the cusp of making the plunge into aftermarket optics Whatever aftermarket optics are - I would not go and by *used* optics, because that's about the only thing in modern hardware that truly ages, aka optics burn out over time. Agreed, general use optics shouldn’t cost you more than $300, and that is being quite generous. If you wanted to program your own optics, apparently you can get one of these new raspberry pis: http://eoinpk.blogspot.com/2014/05/raspberry-pi-and- programming-eeproms-on.html It includes a link at the bottom for how to program the optics to be ‘cisco compatible’. - Jared ___ 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] Non Cisco SFP
As previously mentioned , hidden IOS command service unsupported-transceiver...it is global, not interface level... and for IOS XR I use, interface level, transceiver permit pid all I use non-cisco xcvrs all over the place in my network, they seem fine. Also, ASR901 takes the legacy hidden global command I had to use it somewhat recently. Aaron -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jared Mauch Sent: Monday, February 02, 2015 10:31 AM To: Gert Doering Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Non Cisco SFP On Feb 2, 2015, at 11:16 AM, Gert Doering g...@greenie.muc.de wrote: Hi, On Mon, Feb 02, 2015 at 03:29:41PM +, Rick Martin wrote: I am glad to see this thread, we are on the cusp of making the plunge into aftermarket optics Whatever aftermarket optics are - I would not go and by *used* optics, because that's about the only thing in modern hardware that truly ages, aka optics burn out over time. Agreed, general use optics shouldn’t cost you more than $300, and that is being quite generous. If you wanted to program your own optics, apparently you can get one of these new raspberry pis: http://eoinpk.blogspot.com/2014/05/raspberry-pi-and-programming-eeproms-on.html It includes a link at the bottom for how to program the optics to be ‘cisco compatible’. - Jared ___ 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] Non Cisco SFP
On Feb 2, 2015, at 7:29 AM, Rick Martin rick.mar...@arkansas.gov wrote: We are also looking at aftermarket DAC or Twinax cables, what has been your experience with those in a Cisco environment? We have had a couple dozen Dell DAC's connecting Dell servers to HP 5900's with good success but have not tried any in our Nexus environment. Most _Cisco branded_ 40gb DAC and twinax cables are incompatible with Cisco interfaces. We’ve been having horrible go-arounds with the TAC that keep resulting in the ordering tool compatibility matrix being pared down. Note that you can no longer order 40gb interfaces in UCS servers, by and large, although they’re still orderable as a spare… That’s because none of the 40gb DAC or twinax cables could actually interoperate between that interface and a Nexus switch. Not sure whose idea it was to make them orderable before doing any lab testing. 10gb are all fine, in our experience. -Bill signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] Non Cisco SFP
On Feb 2, 2015, at 11:46 AM, Warren Jackson wrjack1...@gmail.com wrote: Sure, no problem! 1) Lack of Cisco support. You will find yourself behind the eight-ball dealing with the TAC if you have these in your chassis. Sounds like a small deal, but I for one don't have the time to deal with it. Sounds like you work for Cisco or were properly ingrained in their marketing thinking. 2) Cost. If you buy through a Cisco gold provider then you are going to get a good price on the optics, enough to where the difference pays off in support, as these can been wrapped in through your smartnet converage. If you have optics from another vendor you are dealing with their support and Cisco support, keeps things simple. Makes it worth paying the bit extra you would pay. We aren't talking about thousands of dollars difference in price here. Not really. 3) Who? Which SFP manufacturer(s) would you recommend besides Cisco? Finisar (for examples). 4) Several of the Cisco SFP's provide the show tranceiver telemetry that aid in troubeshooting the physical layer, which you won't get with the off-market brand tranceivers. Actually, not true, this is the problem I have with their first party optics. We’ve met with their TMG group several times and have outstanding software defects that are unresolved. Just my 2 cents based on my experience. How about the rest of you guys? We’ve had great luck with 3rd party and better support for DOM than their first party optics. - Jared -Warjack On Mon Feb 02 2015 at 11:37:59 AM Jared Mauch ja...@puck.nether.net wrote: On Feb 2, 2015, at 11:16 AM, Gert Doering g...@greenie.muc.de wrote: Hi, On Mon, Feb 02, 2015 at 03:29:41PM +, Rick Martin wrote: I am glad to see this thread, we are on the cusp of making the plunge into aftermarket optics Whatever aftermarket optics are - I would not go and by *used* optics, because that's about the only thing in modern hardware that truly ages, aka optics burn out over time. Agreed, general use optics shouldn’t cost you more than $300, and that is being quite generous. If you wanted to program your own optics, apparently you can get one of these new raspberry pis: http://eoinpk.blogspot.com/2014/05/raspberry-pi-and-programming-eeproms-on.html It includes a link at the bottom for how to program the optics to be ‘cisco compatible’. - Jared ___ 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] Non Cisco SFP
Hi, On Mon, Feb 02, 2015 at 04:46:30PM +, Warren Jackson wrote: 1) Lack of Cisco support. You will find yourself behind the eight-ball dealing with the TAC if you have these in your chassis. Sounds like a small deal, but I for one don't have the time to deal with it. It will only be a deal if you have issues with that particular interface (like, link not coming up or errors or stuff like that). Our typical dealing with TAC is (besides have you upgraded and rebooted?) more general software issues, or clear hardware brokenness, like oh, we rebooted our 6500 and lost one 6708 module due to memory going bad, and 3rd-party transceivers have never been an issue. 2) Cost. If you buy through a Cisco gold provider then you are going to get a good price on the optics, enough to where the difference pays off in support, as these can been wrapped in through your smartnet converage. If you have optics from another vendor you are dealing with their support and Cisco support, keeps things simple. Makes it worth paying the bit extra you would pay. We aren't talking about thousands of dollars difference in price here. Oh, we *are* (talking about thousands of dollars, that is). The supplier we're currently ordering 10G optics from takes about 70 EUR (+VAT) for a SR SFP+ and about 100 EUR for a LR SFP+, delivery usually on the next day (Cisco partners over here tend to take a week or longer to actually make an offer in the first place). I'm not sure what is charged for a Cisco SFP+ these days, but last time I looked, the 4 SFP+ that go into an ASR9001 would easily save 1000 EUR or more... 3) Who? Which SFP manufacturer(s) would you recommend besides Cisco? Who do you guess makes Cisco SFPs? It's all the same production lines, like Finisair etc. - and guess what, they sell the same modules to other parties as well, just not with a Cisco stamp on it. 4) Several of the Cisco SFP's provide the show tranceiver telemetry that aid in troubeshooting the physical layer, which you won't get with the off-market brand tranceivers. Tell the one you buy the SFPs from that you want DOM support, receive SFPs that have DOM support (and might be 5 EUR more expensive a piece). Of course, if you actually have a *Cisco* box that supports DOM in the first place, which is spotty enough. 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 pgpw_CK_GQrwQ.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] Non Cisco SFP
On 2/Feb/15 18:46, Warren Jackson wrote: Sure, no problem! 1) Lack of Cisco support. You will find yourself behind the eight-ball dealing with the TAC if you have these in your chassis. Sounds like a small deal, but I for one don't have the time to deal with it. I've found this not to be an issue in practice. Mark. ___ 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] Non Cisco SFP
On 2/Feb/15 19:24, Aaron wrote: As previously mentioned , hidden IOS command service unsupported-transceiver...it is global, not interface level... and for IOS XR I use, interface level, transceiver permit pid all I have service unsupported-transceiver in IOS XR and it works with no issues. What is interesting, though, is that these were Cisco optics that required this command. You can imagine how long it took us to fix that knowing well these were shipped by Cisco from the factory, and weren't 3rd party :-). Mark. ___ 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] Non Cisco SFP
On Feb 2, 2015, at 2:19 PM, Mark Tinka mark.ti...@seacom.mu wrote: On 2/Feb/15 18:46, Warren Jackson wrote: Sure, no problem! 1) Lack of Cisco support. You will find yourself behind the eight-ball dealing with the TAC if you have these in your chassis. Sounds like a small deal, but I for one don't have the time to deal with it. I've found this not to be an issue in practice. And if it is, it’s solved with a handful of spares per location. If you have 100 SFPs at one location and you’re saving a few hundred per SFP, keeping a few “genuine” units is a small price if you have TAC paranoia. Charles Mark. ___ 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/
