[c-nsp] All RRs down
Hi, I have a small network running IBGP with 2 designated route reflectors. Everything now is working fine. My question is that, if the 2 RRs are down for some reasons, can other routers in the cluster keep forwarding packets during the down time of RRs? In other words, will routing table or forwarding table of a router remain unchanged if its RRs go down? Thanks. -- Nam Nguyen ___ 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] All RRs down
Hello Nam, I have a small network running IBGP with 2 designated route reflectors. Everything now is working fine. My question is that, if the 2 RRs are down for some reasons, can other routers in the cluster keep forwarding packets during the down time of RRs? In other words, will routing table or forwarding table of a router remain unchanged if its RRs go down? no, as your BGP routes would go away. This is why redundant route reflectors are a must. Sascha ___ 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] Nexus 5000 / Nexus 2000 SFP+ with LRM
On Sun, 9 May 2010 22:17:11 +0200, Daniel Roesen wrote On Sat, May 08, 2010 at 07:01:48AM +1000, Lincoln Dale wrote: i doubt anyone has successfully deployed it as LRM is not supported on N5K or N2K. there are technical reasons behind why its not supported. Could you elaborate on that? LRM SFP+ is just part of the stuff you need. For LRM to work, the switch linecard must have appropriate EDC functionality. If it's not there, it simply won't work. (One more thanks to all people who thought that analog interface between SFP+ and linecard is a good idea...) On a similar topic, I'm still waiting for an explanation, why Cisco doesn't support SR XFPs in SPA-1X10GE-L-V2 when used in uBR10k systems... LR XFPs are fine though. This is completely different situation, though. There's absolutely no reason why SR (or any other MSA-compliant XFP) shouldn't work there, so the whole story is that not enough customers asked for SR in this SPA. ___ 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] All RRs down
On Monday 10 May 2010 02:23:42 pm Nam NGUYEN wrote: I have a small network running IBGP with 2 designated route reflectors. Everything now is working fine. My question is that, if the 2 RRs are down for some reasons, can other routers in the cluster keep forwarding packets during the down time of RRs? In other words, will routing table or forwarding table of a router remain unchanged if its RRs go down? If the route reflectors are down, the routers won't know of BGP routes after various timers expire. However, they should have some knowledge of IGP routes (I say some because your IGP configuration may or may not necessarily permit all routers having knowledge of all IGP routes). You can use IETF Graceful Restart (if supported) between iBGP clients and their route reflectors so they can maintain forwarding state as the route reflectors restart (assuming they plan to restart), however, how long they can do so depends on the configured Graceful Restart timers. Also, any changes in the network during the restart period are not captured, but this may not be a huge problem as they might reflect a negligible % of your overall traffic being switched at the time if the route reflectors return to a functional state in a timely fashion. 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] Nexus 5000 / Nexus 2000 SFP+ with LRM
On Mon, May 10, 2010 at 08:34:05AM +0200, Marian ??urkovi?? wrote: LRM SFP+ is just part of the stuff you need. For LRM to work, the switch linecard must have appropriate EDC functionality. If it's not there, it simply won't work. Interesting. Thanks. On a similar topic, I'm still waiting for an explanation, why Cisco doesn't support SR XFPs in SPA-1X10GE-L-V2 when used in uBR10k systems... LR XFPs are fine though. This is completely different situation, though. There's absolutely no reason why SR (or any other MSA-compliant XFP) shouldn't work there, so the whole story is that not enough customers asked for SR in this SPA. Well, SR _are_ supported in SPA-1X10GE-L-V2 when used in CRS-1, SCE8000 and ASR1000, just not uBR10k. Unfortunately I'm currently lacking an original Cisco SR XFP to try wether it works technically. Cisco SE claims IOS would reject the XFP. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- d...@ircnet -- PGP: 0xA85C8AA0 ___ 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] Error: Write byte status SP error on 6500?
On Sun, 2010-05-09 at 19:51 +0100, Rob Shakir wrote: We had something similar a while back, I progressed it via TAC and it was matched to CSCsi68355, this was only on standby SUPs in 12.2(33)SXH I believe. The TAC engineer expanded on the (minimal) bug notes with: It is a cosmetic issue. It occurs when OBFL application tries to write flash sectors without erasing them. where OBFL == on-board failure logging. There did not seem to be any specific process that we could trace this to - but it was being examined internally. It wasn't high enough priority for me to progress any further. Sounds similar enough to your issue that it might explain it. It does sound a lot like that, even though we don't have a standby sup. We haven't had any issues with the switch in question, so we'll just wait and see. Thank you for the information. :-) -- Peter ___ 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] Nexus 5000 / Nexus 2000 SFP+ with LRM
On Mon, May 10, 2010 at 09:51:39AM +0200, Daniel Roesen wrote: Well, SR _are_ supported in SPA-1X10GE-L-V2 when used in CRS-1, SCE8000 and ASR1000, just not uBR10k. I have to partially correct myself here. I can personally testify that they are supported in ASR1000 (see also Release Notes IOS-XE 2.1) and in SCE8000 (at least we've been offered SPA-1X10GE-L-V2 + XFP-10G-MM-SR on those). Not sure on CRS-1, 7600, XR-GSR. Others might be able to confirm? Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- d...@ircnet -- PGP: 0xA85C8AA0 ___ 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] Nexus 5000 / Nexus 2000 SFP+ with LRM
On 10/05/2010 08:34, Marian Ďurkovič wrote: LRM SFP+ is just part of the stuff you need. For LRM to work, the switch linecard must have appropriate EDC functionality. If it's not there, it simply won't work. To give some back-ground on this, LRM is long-reach multimode. As it's multimode, modal dispersion comes into play pretty quickly, and even over relatively short distances, it causes severe signal distortion - this is one of the primary distance limiting factors of multimode. On xenpaks, x2 and xfp, the dispersion compensation is performed on the transceiver (by the EDC), and you end up with a fully digital signal being transmitted from the transceiver's electrical interface to the line card. However as the SFP+ form factor is really tiny, there isn't enough room to house various components such as an EDC or a CDR (clock / data recovery). For SFP+, these components are housed on the line card, if at all, and in many cases the line card simply won't have EDC. Perhaps the n5k main board doesn't have EDC processors, which would make it unsuitable for LRM. (One more thanks to all people who thought that analog interface between SFP+ and linecard is a good idea...) Fibre and transceiver deployments are all about choosing the appropriate technology. If you need to run fibre over longer distances, doing this over MMF probably isn't the best idea. I appreciate that lots of organisation have cartloads of legacy 62.5µ MMF and that they tend to be unhappy about the prospect of changing longer runs to use SMF, but 62.5µ wasn't designed for longer runs at very high speeds. In some senses, you might as well complain that SFP+ isn't physically large enough to house enough lasers for LX4. 10G standards like LX4 and LRM were only created to try to deal with legacy plant deployments which weren't really designed for anything more than 100M-FX. Anyone sensible MMF deployment done over the past couple of years will have been OM3, where you can use SR transceivers instead of LRM or LX4. If you need distances longer than 200m, LR + SMF is a better choice of technology to use. 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] All RRs down
Hi all, Thanks a lot for your quick feedbacks. I now have a better understanding of the scenario. In my network, the optical links between the client routers and RRs have had problem a few times due to transportation faults from service provider, so I'm now afraid of a time when they all die. Thank you! -- Nam Nguyen ___ 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] FWSM ASR GROUP config ??
FWSM running 4.0(6) transparent mode with sup 720 SXI3 I have 3 bridge groups configured on a FWSM and each connects to a different ISP. Each bridge has an INSIDE and OUTSIDE interface, with the OUTSIDE connected to each ISP. I currently have all the INSIDE interfaces in one ASR-GROUP and the OUTSIDE in a different one. We have had strange problems when one of the ISPs went briefly down and up, and due to the ASR config the FWSM tries to retain the connection state during the DOWN time by looking in the ASR group for the session that is now arrives on a different ISP. Sometimes one of the ISPs stop working and we have to clear the connection table to get things going again. Q. Could I have the ASR GROUPS wrong, and should have both INSIDE and OUTSIDE in same ASR GROUP? Or only OUTSIDE in ASR GROUP? I have not yet received an answer from TAC, and the doc does not clarify how it should be configured. Thanks for any help. Jeff Fitzwater OIT Network Communications 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] All RRs down
On Monday 10 May 2010 11:02:20 pm Nam NGUYEN wrote: Thanks a lot for your quick feedbacks. I now have a better understanding of the scenario. In my network, the optical links between the client routers and RRs have had problem a few times due to transportation faults from service provider, so I'm now afraid of a time when they all die. I'm unfamiliar about your topology, but you might consider looking for ways to reduce dependence on route reflectors that are far away from clients separated by shaky transport links. How you do this is very specific to your setup, so all I can offer is a general idea on how to mitigate against a total route reflector blackout for part of your network. 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] combing 7600 power supplies
I migrated from a 2500w AC power supplies (running at 120v/1250w) to 2500w DC power supplies without any reboots or problems so you can mix and match AC/DC supplies of the same rating. - Kevin Jason Lixfeld wrote: As long as the power supply you are installing is exactly the same as the power supply that is in there currently, you should be able to insert it, power it up and configure combined mode (if it's not that by default already) without an issue. If you try to install and power up a higher output supply, it will shut down the lower output supply and your box will reboot as power is shifted from the lower output supply to the higher output supply. On 2010-05-05, at 8:06 AM, Ibrahim Abo Zaid wrote: hi group i have a problem and will need to combine the power supplies of 7609 router (changing the mode from redundant to combine) based on your experience , is this step can take the router down if one power supply is enough now but i need to insert new modules so i need to combine the other one ? thanks --ibrahim ___ 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/
[c-nsp] 3750-E + CVR-X2-SFP10G + SFP-10G-SR = disappearing media
Greetings, I have an open TAC case about this but I figured I'd ask here as well. I recently installed 10 3750-Es in 5 2-member stacks. Each stack has 2 uplinks to a 6509-VSS. I'm using X2 to SFP+ converters and 10G SFP+ modules on both ends of the links between the stacks and the VSS. In each stack I'm using interface Ten1/0/1 and Ten2/0/1. There is currently no real traffic on any of the links. The plan is to do a forklift upgrade of our existing production network and I've set the 3750/VSS up in a test environment. With the exception of two hosts talking iperf to each other, the network is quiet. The problem I'm seeing is this: after about 6 to 8 hours a 10G interface on the 3750 side will go down. Saying 'show int Ten2/0/1' will show the media type as Not Present: Full-duplex, 10Gb/s, link type is auto, media type is Not Present as opposed to: Full-duplex, 10Gb/s, link type is auto, media type is SFP-10GBase-SR I am seeing this behavior on three individual switches and in each case it is ten2/0/1 that fails. I've replaced the X2 converter, the SFP+ module and moved the converter to Ten2/0/2 but the symptoms persist. I RMA'd one of the switches and just installed the replacement, hopefully this will solve the problem. I also checked software compatibilty and the switches are running (C3750E-UNIVERSALK9-M), Version 12.2(53)SE2 Has anyone seen this before? -mtw ___ 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] combing 7600 power supplies
On 2010-05-10 22:21, Kevin Loch wrote: I migrated from a 2500w AC power supplies (running at 120v/1250w) to 2500w DC power supplies without any reboots or problems so you can mix and match AC/DC supplies of the same rating. Right. No mysterious reboots should be observed when moving the power supplies, even if one is higher/lower wattage than the other. Just make sure the one that will be left in the chassis for a moment has enough power to hold all the system/LCs up and running which is pretty obvious. Take a look here BTW: http://cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a008015bfa8.shtml -- Everything will be okay in the end. | Łukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net ___ 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] Routing SSDP for Windows Desktops
Thanks, that worked. But I wonder if windows allows this? I can now see the device, but it seems I have no access if i'm on a different subnet. Dan. On Sun, May 9, 2010 at 11:43 PM, Anton Kapela tkap...@gmail.com wrote: On May 9, 2010, at 10:17 PM, Dan Letkeman wrote: Am I missing something? Or does this just not work? Well, ttl=1 always wins, or doesn't, so to speak. AFAIK, ssdp mcast destined packets are ttl=1 on winders by default. Not authoritative in all cases, but this seems spot on: http://msdn.microsoft.com/en-us/library/aa381091%28VS.85%29.aspx -Tk ___ 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] Cannot join a few multicast groups
I'm having trouble joining some multicast streams. The upstream router joins it fine. The upstream has (*,G) and (S,G) in the mroute table. Downstream doesn't have (S,G). This is a sparse mode environment with a static RP. From the router with trouble I can ping the mcast group and get responses from the group members. I can ping the unicast source of the group, the RP..anything I can think of to rule out an RPF problem. Keep in mind that we're having trouble with 5 out of ~400 multicast groups. Of course nothing that we know has changed at all. Thanks ___ 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/
