[c-nsp] BGP cause dropped packet
Hello, I have some problem about BGP ipv6 and need your kindly advice. I have 2 router CISCO7606-S 12.2(33)SRE1 as core router redundancy, normally using eBGP with any other routers. Right now, I need to enable BGP IPv6 on both routers. One of them has experienced dropped packet whenever enable BGP IPv6, if disable, then no any dropped packet, but another has not. Do you have experience this before, can you please advice how to investigate this problem? which PING result are shown below; !!!..! !! .!!!.! !!!.!! !!!.!. !!!..! !.!!!. !!!.!! !!!.!!..!! !! .! !!!.!!!.!! !!..!!..!!!.!! !!!.!! Success rate is 97 percent (976/1000), round-trip min/avg/max = 1/2/212 ms After disable BGP IPv6, no any lost packet. Thanks a lot for kind help. Rojarek ___ 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] OSPFv3 Adjacency issues between 2921 and 3750
Any difference without authentication? Does the 3750 respond to pings to ff02::5? On Mon, Jul 2, 2012 at 4:16 PM, Peter Subnovic wrote: > Dear list members, > > i am having a somewhat odd issue (again) and i am out of ideas what is > causing it. > > Let's assume the following very simple topology > > 2921 <> 3750G-24PS > > All i want is to establish an OSPFv3 Adjacency between these two devices. > Here is where the fun (headache) begins: > > The 2921 is running 15.1(4)M3 and the 3750G is running 12.2(55)SE5. > > So i configured OSPv3 on both sides on the respective Interfaces and > wondered why the adjacency wont come up. > > After a little bit of troubleshooting it appears that the 3750G does not > "recognize" the hello packets from the 2921. I can see in the debug output > that they are received by the switch, but the OSPFv3 Process does not > recognize them as such. > > Please see the debug output below: I had debugging for IPv6 Packets and > OSPFv3 Hellos enabled. FE80::1 = 2921, FE80::2 = 3750G > > Jun 30 17:00:38.347 CEST: IPV6: source FE80::1 (GigabitEthernet1/0/24) > Jun 30 17:00:38.347 CEST: dest FF02::5 > Jun 30 17:00:38.347 CEST: traffic class 224, flow 0x0, len 80+14, > prot 89, hops 1, forward to ulp > Jun 30 17:00:41.057 CEST: OSPFv3: Send hello to FF02::5 area 0 on > GigabitEthernet1/0/24 from FE80::2 interface ID 1040 > Jun 30 17:00:41.057 CEST: IPV6: source FE80::2 (local) > Jun 30 17:00:41.057 CEST: dest FF02::5 (GigabitEthernet1/0/24) > Jun 30 17:00:41.057 CEST: traffic class 224, flow 0x0, len 76+0, prot > 89, hops 1, originating > Jun 30 17:00:41.057 CEST: IPv6-Fwd: Sending on GigabitEthernet1/0/24 > > As you can see, the hello packet arrives on the interface, but somehow the > OSPFv3 process on the 3750 does not "recognize" them as such. After digging > around i found the following bug and thought it could be related: > > CSCtr55645 > > IPv6 multicast packets for routing protocols (such as OSPFv3 hello > messages) are not enqueued to CPU queue 3 as expected. > > So i upgraded to 12.2(55)SE5 (where this bug should be fixed) this weekend > in the hope to resolve issue, but still the same. I am really kinda lost > here. > > The 2921 does see the hello packets from the 3750 and the adjacency is in > the INIT State as i would have it expected. > > show ipv6 ospf neighbor > > Neighbor ID Pri State Dead Time Interface IDInterface > 1.2.3.4 0 INIT/ -00:00:361040 > GigabitEthernet0/1 > > So has anybody seen this strange behavior or has an idea what is causing > the issues? I rebooted the 3750, cleared the ospf processes on both sides, > no luck I dont wanna rule out that i maybe just missed something. > > Please see below the relevant configuration of the respective Interfaces: > > 2921: > > interface GigabitEthernet0/1 > description ===XXX=== > ip address XXX > no ip redirects > no ip proxy-arp > ip flow ingress > ip flow egress > ip ospf authentication message-digest > ip ospf message-digest-key 1 md5 7 > ip ospf network point-to-point > ip ospf 1 area 0 > load-interval 30 > duplex auto > speed auto > ipv6 address FE80::1 link-local > ipv6 enable > ipv6 nd ra suppress all > no ipv6 redirects > ipv6 ospf network point-to-point > ipv6 ospf 1 area 0 > no cdp enable > no mop enabled > > ipv6 router ospf 1 > router-id 1.1.1.1 > > === > > 3750G > > interface GigabitEthernet1/0/24 > description ===xxx=== > no switchport > ip address xxx 255.255.255.252 > no ip proxy-arp > no ip redirects > ip ospf authentication message-digest > ip ospf message-digest-key 1 md5 7 xxx > ip ospf network point-to-point > ip ospf 1 area 0 > no keepalive > ipv6 address FE80::2 link-local > ipv6 enable > ipv6 nd ra suppress > no ipv6 redirects > ipv6 ospf network point-to-point > ipv6 ospf 1 area 0 > no cdp enable > > ipv6 router ospf 1 > router-id 1.2.3.4 > log-adjacency-changes > > If you need any additional input or show commands, please dont hesitate to > ask. > > I appreciate all hints/comments. > > Thanks in advance, > > 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/ ___ 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] C6k power reserved for redundant sup?
Hi, > As Andy points out the 6509-V-E does not have "special" slots (apart > from the supervisor ones of course). And by "aesthetic reasons" I mean > things like cable management. It's probably not a big thing since we > seldomly change anything (it's all supposed to cabled at deployment > time) but we still like it to be neat. I prefer my network to be in a working state than neat...but hey, some people think that the data centre needs to look like a beauty contest ;-) this, by the way, DOESNT mean that I like some rats nest of unknown cables. there are important rules 1) cables must be labelled (at both ends! and bonus points for extra labels at inspection points) 2) cables must run as neatly as to make changes easy and efficient 3) cables should not trap equipment..or be trapped by equipment 4) use the correct coloured cables 5) broken retain clip? cable gets binned. 6) install every cable as if its there for the long term no 'its just a quick bodge/fix that'll go' (it never goes...its there in a years time...) 7) If a contractor could snag it, they will - ensure cables are secured and contained. I'm sure theres more but those are the top of the list. overly neat/hidden cables make routine work very awkward and frustrating I dont think theres a 'cabling' course in the line of CCNA...I wish there were...the number of sites I've been to...or people I've dealt with that dont care for this makor part of the network...if the PHY layer cannot be controlled then forget anything travelling on it alan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ME3600X IOS Version
Hi Waris, It is SR 620762785 Tnx in advance Regards, Faruk On 2.7.2012 10:56, Waris Sagheer (waris) wrote: Faruk, Can you send me the SR number for the following issue? It should be fixed in 15.2(2)S too. Let me confirm the release and will get back to you. Regards, Waris -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Faruk Sejdic Sent: Monday, June 25, 2012 4:22 AM To: cisco-nsp@puck.nether.net Cc: cisco-nsp-requ...@puck.nether.net Subject: Re: [c-nsp] ME3600X IOS Version It's hard to say, we're still waiting for right release. :( We already tried all this versions but all of them have serious bugs. Even with new 15.2(2)S1 we hit a bug with Multicast Traffic Failure on EVC Interface In general, if you have EVC on interface configured with IPTV VLAN (mostly multicast traffic) and tried to add this EVC to an other interface multicast stops. Cisco TAC says this should be fixed in 15.2(4)S. :) Regards Faruk I'd recommend 15.2(2)S1. 15.1(2)EY is a branch release which probably won't have a long lifespan now that these switches have been integrated into mainline S code. 15.2(2)S1 has been solidly stable for us with the exception of what appears to be a cosmetic bug in that these messages are printed to the console: "Jun 25 17:10:02.164: %SFF8472-3-THRESHOLD_VIOLATION: Te0/2: Rx power high alarm; Operating value: 1.4 dBm, Threshold value: 0.0 dBm." I vaguely recall seeing a DDTS Caveat about this problem too. Otherwise all good, no other issuesand really like the hardware. Reuben On 25/06/2012 5:08 PM, Ivan wrote: Hi, I know the ME3600X has come up quite a lot recently on this list, but as far as I recall and can find, it has been a while since there have been any comments regarding the "best/most stable" version. I am currently running 151-2.EY but will deploying some more hardware shortly and would be interested what versions others are successfully using, especially 15.2S or 15.2S1. 151-2.EY has been good so far but I am aware of the rapid development on software for this platform and also that there are quite a few issues around. ___ 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] C6k power reserved for redundant sup?
On Mon, 2012-07-02 at 19:53 +0100, alan buxey wrote: > choosing a slot due to aesthetic reasons is not the best of ideas - > you are aware that on the 6500 chassis certain slots are poorer than > others? As Andy points out the 6509-V-E does not have "special" slots (apart from the supervisor ones of course). And by "aesthetic reasons" I mean things like cable management. It's probably not a big thing since we seldomly change anything (it's all supposed to cabled at deployment time) but we still like it to be neat. -- 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] m-vpn
On Monday, July 02, 2012 10:24:55 PM Gert Doering wrote: > Now that depends a bit on the working group you're > talking to... > > ... secure-BGP-over-DNS seems about as likely :-9 Hehe, Rover... touche :-). 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] OSPFv3 Adjacency issues between 2921 and 3750
Hi Mikael, thanks for the input. Unfortunately i can not set the IPv6 MTU on the 3750. According to the show ipv6 int xx output, both sides have an mtu of 1500 3750: === GigabitEthernet1/0/24 is up, line protocol is up IPv6 is enabled, link-local address is FE80::2 No Virtual link-local address(es): No global unicast address is configured Joined group address(es): FF02::1 FF02::2 FF02::5 FF02::1:FF00:2 MTU is 1500 bytes 2921 GigabitEthernet0/1 is up, line protocol is up IPv6 is enabled, link-local address is FE80::1 No Virtual link-local address(es): No global unicast address is configured Joined group address(es): FF02::1 FF02::2 FF02::5 FF02::6 FF02::1:FF00:1 MTU is 1500 bytes Thanks for your time. Kind regards, Peter On Mon, Jul 2, 2012 at 10:33 PM, Mikael Abrahamsson wrote: > On Mon, 2 Jul 2012, Peter Subnovic wrote: > > If you need any additional input or show commands, please dont hesitate >> to ask. >> > > MTU issue? Try setting ipv6 mtu 1500 at both ends and see if that changes > anything? > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > ___ 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] m-vpn
Hi, On Sun, Jul 01, 2012 at 11:06:34PM +0200, Mark Tinka wrote: > I always said, with the way the IETF are going, we shall > soon see BGP carrying DNS. Now that depends a bit on the working group you're talking to... ... secure-BGP-over-DNS seems about as likely :-9 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 pgpc4OSGceq9Y.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/
[c-nsp] OSPFv3 Adjacency issues between 2921 and 3750
Dear list members, i am having a somewhat odd issue (again) and i am out of ideas what is causing it. Let's assume the following very simple topology 2921 <> 3750G-24PS All i want is to establish an OSPFv3 Adjacency between these two devices. Here is where the fun (headache) begins: The 2921 is running 15.1(4)M3 and the 3750G is running 12.2(55)SE5. So i configured OSPv3 on both sides on the respective Interfaces and wondered why the adjacency wont come up. After a little bit of troubleshooting it appears that the 3750G does not "recognize" the hello packets from the 2921. I can see in the debug output that they are received by the switch, but the OSPFv3 Process does not recognize them as such. Please see the debug output below: I had debugging for IPv6 Packets and OSPFv3 Hellos enabled. FE80::1 = 2921, FE80::2 = 3750G Jun 30 17:00:38.347 CEST: IPV6: source FE80::1 (GigabitEthernet1/0/24) Jun 30 17:00:38.347 CEST: dest FF02::5 Jun 30 17:00:38.347 CEST: traffic class 224, flow 0x0, len 80+14, prot 89, hops 1, forward to ulp Jun 30 17:00:41.057 CEST: OSPFv3: Send hello to FF02::5 area 0 on GigabitEthernet1/0/24 from FE80::2 interface ID 1040 Jun 30 17:00:41.057 CEST: IPV6: source FE80::2 (local) Jun 30 17:00:41.057 CEST: dest FF02::5 (GigabitEthernet1/0/24) Jun 30 17:00:41.057 CEST: traffic class 224, flow 0x0, len 76+0, prot 89, hops 1, originating Jun 30 17:00:41.057 CEST: IPv6-Fwd: Sending on GigabitEthernet1/0/24 As you can see, the hello packet arrives on the interface, but somehow the OSPFv3 process on the 3750 does not "recognize" them as such. After digging around i found the following bug and thought it could be related: CSCtr55645 IPv6 multicast packets for routing protocols (such as OSPFv3 hello messages) are not enqueued to CPU queue 3 as expected. So i upgraded to 12.2(55)SE5 (where this bug should be fixed) this weekend in the hope to resolve issue, but still the same. I am really kinda lost here. The 2921 does see the hello packets from the 3750 and the adjacency is in the INIT State as i would have it expected. show ipv6 ospf neighbor Neighbor ID Pri State Dead Time Interface IDInterface 1.2.3.4 0 INIT/ -00:00:361040 GigabitEthernet0/1 So has anybody seen this strange behavior or has an idea what is causing the issues? I rebooted the 3750, cleared the ospf processes on both sides, no luck I dont wanna rule out that i maybe just missed something. Please see below the relevant configuration of the respective Interfaces: 2921: interface GigabitEthernet0/1 description ===XXX=== ip address XXX no ip redirects no ip proxy-arp ip flow ingress ip flow egress ip ospf authentication message-digest ip ospf message-digest-key 1 md5 7 ip ospf network point-to-point ip ospf 1 area 0 load-interval 30 duplex auto speed auto ipv6 address FE80::1 link-local ipv6 enable ipv6 nd ra suppress all no ipv6 redirects ipv6 ospf network point-to-point ipv6 ospf 1 area 0 no cdp enable no mop enabled ipv6 router ospf 1 router-id 1.1.1.1 === 3750G interface GigabitEthernet1/0/24 description ===xxx=== no switchport ip address xxx 255.255.255.252 no ip proxy-arp no ip redirects ip ospf authentication message-digest ip ospf message-digest-key 1 md5 7 xxx ip ospf network point-to-point ip ospf 1 area 0 no keepalive ipv6 address FE80::2 link-local ipv6 enable ipv6 nd ra suppress no ipv6 redirects ipv6 ospf network point-to-point ipv6 ospf 1 area 0 no cdp enable ipv6 router ospf 1 router-id 1.2.3.4 log-adjacency-changes If you need any additional input or show commands, please dont hesitate to ask. I appreciate all hints/comments. Thanks in advance, 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] C6k power reserved for redundant sup?
On Mon, Jul 2, 2012 at 1:53 PM, alan buxey wrote: > choosing a slot due to aesthetic reasons is not the best of ideas - you > are aware that on the 6500 chassis certain slots are poorer than others? At the risk of veering OT...while this is true on the non-E 6513 chassis, Peter appears to have a 6509 and therefore all slots should be created equal. ___ 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] 7600 w/ WS-SUP720-3B IOS 15.x
What they *could* easily do is support the 7600 chassis in the Catalyst 6500 software 15.0 SY. That I think they might, and there's kind of a poetic justice in it if they do, because everything would then be back to square one. Maybe, just because of that, they won't: It would look like they made a mistake when they split the two products. == I believe Cisco is back to square one. Went down the 2T path with our account team only to find that the EVC model is not supported with EoMPLS or VPLS. I wouldn't go so far as to say it is a mistake but from a customer's perspective, the confusion does make my head hurt. http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/15.0SY/release _notes.html#wp2560852 New Hardware Features in Release 15.0(1)SY1 [snip] .Cisco 7609-S chassis (CISCO7609-S) Cheers, Jay McMaster, Consultant Advanced IP Solutions Inc. ___ 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] C6k power reserved for redundant sup?
Hi, > We'll have to consider if we try to find new PSUs (we have some 6000W in > some remote boxes that could cope with 3000W) or move the module. We > prefer to use slot 8 for aesthetic reasons but nobody really looks that > these boxes that much. choosing a slot due to aesthetic reasons is not the best of ideas - you are aware that on the 6500 chassis certain slots are poorer than others? we just put our module into the slot that the reserved power was on - as we run with just 1 supervisor (we have other resilience/redundancy methods that dont rely on the 2nd sup hackiness) alan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 7600 w/ WS-SUP720-3B IOS 15.x
The Sup2T works on the 7600 platform with compatible line cards. The ES+ is reported to be planned for compatibility with Sup2T. No word yet if it is a part swap or line card swap. Mack -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Asbjorn Hojmark - Lists Sent: Monday, July 02, 2012 6:04 AM To: 'Rinse Kloek' Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 7600 w/ WS-SUP720-3B IOS 15.x > Does any of you already heard about the successor of the RSP720 for > the 7600 ? I don't think it would make a lot of sense, and I don't think we'll ever see one. If they rebrand the Sup2T as RSP2T, they would have close to no supported line cards (only 67xx without DFCs) and, specifically, all of the high-functionality line cards (ES+) wouldn't be supported. Yes, they could support 68xx and 69xx and spin new ES cards (ES++), but that would be fairly expensive. And for what purpose? If you have a 7600 and you need to replace everything but the chassis and PSUs to upgrade to higher speeds, does it make sense to do so, when there's already the ASR 9000 available? A much better router at presumably approx. the same production cost as a 7600 full of ES+. In my opinion, no. What they *could* easily do is support the 7600 chassis in the Catalyst 6500 software 15.0 SY. That I think they might, and there's kind of a poetic justice in it if they do, because everything would then be back to square one. Maybe, just because of that, they won't: It would look like they made a mistake when they split the two products ;-) (Hi Gert!) -A ___ 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] C6k power reserved for redundant sup?
On Mon, 2012-07-02 at 13:10 -0500, Andy Ellsworth wrote: > Decent historical coverage here: > > http://www.gossamer-threads.com/lists/cisco/nsp/41266 Thank you Saku, Gary, Andy. I couldn't see the forest for the trees there. :-) We'll have to consider if we try to find new PSUs (we have some 6000W in some remote boxes that could cope with 3000W) or move the module. We prefer to use slot 8 for aesthetic reasons but nobody really looks that these boxes that much. -- 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] IPv6 Stateful DHCP on ISR 880
On 02/07/2012 18:54, Gert Doering wrote: > Not using a /64 for the LAN. To flesh this out, there is no subnet mask option in dhcpv6: it's hard-coded to /64 because the default lan subnet is /64. I.e. even though the "address prefix" command gives you the impression that it will accept /96, this mask is not transmitted to the dhcpv6 client. It's the client which applies the /64 mask. If you're doing subnetting for a big number of sites, you should ask for enough address space for them all. There's plenty of IPv6 address space around - no need to conserve it. In fact, your provider should be able to give you a /48 without any justification at all: that's 2^16 subnets. Are you really operating more than 65k v6 subnets? 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] 7600 w/ WS-SUP720-3B IOS 15.x
The Sup-2T will work in the 7600 or the 6500 with SY code. Mack -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rinse Kloek Sent: Sunday, July 01, 2012 12:33 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 7600 w/ WS-SUP720-3B IOS 15.x On 1-7-2012 19:47, Gert Doering wrote: > Hi, > > On Sun, Jul 01, 2012 at 06:42:07PM +0200, ?ukasz Bromirski wrote: >> Yep, Asbjorn has it right. 15.0SY is the current line, and 12.2SX is >> going out. The roadmap for 15.0SY, and where things converge is still >> lurking somewhere in the dark. The 6500 architecture session on the >> recent Cisco Live covered this in some detail. > Thanks for the pointer. Reading up on recent innovations now... > > gert Anybody a link to this document ? Does any of you already heard about the successor of the RSP720 for the 7600 ? I heard some rumours that the SUP2T (named RSP-2T) will be released for the 7600 platform also. Rinse ___ 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] C6k power reserved for redundant sup?
Decent historical coverage here: http://www.gossamer-threads.com/lists/cisco/nsp/41266 ___ 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] C6k power reserved for redundant sup?
On (2012-07-02 20:00 +0200), Peter Rathlev wrote: > placing an extra supervisor in this box, but I can't see how to avoid > this reservation. Would anybody here know of a way to do that? Insert linecard in that slot. -- ++ytti ___ 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] C6k power reserved for redundant sup?
So there I was, just having OIR-inserted an extra WS-X6708-10GE in one of our existing core switches. But it didn't boot up because we don't have enough juice. :-( We should of course just install large PSUs (replacing WS-CAC-3000W) but it'll take some time to order these. Looking at the output from "show power" I can see that the box reserves 328.44 W for a redundant supervisor. We have no intention of ever placing an extra supervisor in this box, but I can't see how to avoid this reservation. Would anybody here know of a way to do that? It runs SXI1 AIS and the log message when inserting the module was: 005641: Jul 2 16:54:45.578 CEST: %C6KPWR-SP-4-POWERDENIED: insufficient power, module in slot 8 power denied. The output from "show power": system power redundancy mode = redundant system power total = 2771.16 Watts (65.98 Amps @ 42V) system power used = 2381.40 Watts (56.70 Amps @ 42V) system power available = 389.76 Watts ( 9.28 Amps @ 42V) Power-Capacity PS-Fan Output Oper PS Type Watts A @42V Status Status State -- --- -- -- -- - 1WS-CAC-3000W 2771.16 65.98 OK OK on 2WS-CAC-3000W 2771.16 65.98 OK OK on Pwr-Allocated Oper Fan Type Watts A @42V State -- --- -- - 1WS-C6509-V-E-FAN252.00 6.00 OK 2WS-C6509-V-E-FAN252.00 6.00 OK Pwr-Requested Pwr-Allocated Admin Oper Slot Card-Type Watts A @42V Watts A @42V State State -- --- -- --- -- - - 1WS-X6748-GE-TX 325.50 7.75 325.50 7.75 onon 2WS-X6748-GE-TX 325.50 7.75 325.50 7.75 onon 4WS-X6724-SFP125.16 2.98 125.16 2.98 onon 5WS-SUP720-3BXL 328.44 7.82 328.44 7.82 onon 6(Redundant Sup) - - 328.44 7.82 - - 8WS-X6708-10GE 444.36 10.58 - - onoff (FRU-power denied) 9WS-X6708-10GE 444.36 10.58 444.36 10.58 onon Trying to power down module 6 fails: SomeSwitch(config)#no power enable module 6 %Error: nonexistent FRU SomeSwitch(config)# Thanks a bunch for any pointers. The box is too critical to use combined powering by the way. -- 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] 7600 w/ WS-SUP720-3B IOS 15.x
15.xSY is the re-merge of SX and SRD trains (ie. Runs on 6500 and 7600). Mack -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering Sent: Sunday, July 01, 2012 3:01 AM To: Asbjorn Hojmark - Lists Cc: 'Gert Doering'; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 7600 w/ WS-SUP720-3B IOS 15.x Hi, On Sat, Jun 30, 2012 at 11:40:58PM +0200, Asbjorn Hojmark - Lists wrote: > On Sat, Jun 30, 2012 at 11:10:26PM +0200, ?ukasz Bromirski wrote: > >> Numer of trains is limited, development is more focused, and the > >> code reuse is progressing. > > > 12.2SX next, please :-) > > That's 15.0 SY Well, I was asking for SX-for-6500 (SXI, SXJ), not whatever else might be using an IOS called 12.2SX. 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 ___ 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] IPv6 Stateful DHCP on ISR 880
Hi, On Mon, Jul 02, 2012 at 12:37:54PM -0500, Juan Mario Duenas Preciado wrote: > Could anyone give a hint on where am I wrong? Not using a /64 for the LAN. If your network is not big enough for your number of subnets, get a bigger one from your provider. (I'm somewhat curious, admittedly, to see the first network where a /48 will not have enough /64s to number all subnets) I can't speak for other regions, but in RIPE land, the policies very clearly allow giving large-enough addresses to a customer/enterprise/ network (whatever you are) to make sure that end-users will NEVER have to use non-/64 networks or N:1 NAT. (Some still think that's a good reason, but don't blaim it on address policy). 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 pgprBanfoDIYL.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/
[c-nsp] IPv6 Stateful DHCP on ISR 880
Hi everybody, I'm trying to set up a stateful DHCPv6 server in a cisco ISR 880 with an IOS c880data-universalk9-mz.151-2.T4.bin but I'm having some issues. The router have to give IPv6 addresses just like a DHCPv4 do in its VLAN2 interface using the 2801:C4:10:3012:0:1::/96 prefix (I'm was not able to use /64 prefixes because I'm subnetting for a big number of sites). These are the lines for DHCPv6 that I'm using for the DHCP server: ipv6 unicast-routing ipv6 cef ipv6 dhcp database USUARIOSv6 ipv6 dhcp pool DATOS address prefix 2801:C4:10:3012:0:1::/96 lifetime 3600 3500 link-address FE80::C664:13FF:FEEA:5BAC/12 dns-server FEC0::1 domain-name this.is.a.test information refresh 7 ! interface Vlan2 ipv6 address 2801:C4:10:3012:0:1:0:1/96 ipv6 enable no ipv6 redirects no ipv6 unreachables ipv6 dhcp server DATOS Now, when I use my Windows 7 client to request an IPv6 address nothing happens but when I use my Linux client it works but it says that it received a /64 prefix (more exactly the 2801:C4:10:3012:0:1:FC44:7E8C/64 address) Could anyone give a hint on where am I wrong? or at least to share an experience about using IPv6 stateful DHCP? Thanks in advance, greetings! -- Mario D. P. ___ 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] 7600 w/ WS-SUP720-3B IOS 15.x
> Does any of you already heard about the successor of the RSP720 > for the 7600 ? I don't think it would make a lot of sense, and I don't think we'll ever see one. If they rebrand the Sup2T as RSP2T, they would have close to no supported line cards (only 67xx without DFCs) and, specifically, all of the high-functionality line cards (ES+) wouldn't be supported. Yes, they could support 68xx and 69xx and spin new ES cards (ES++), but that would be fairly expensive. And for what purpose? If you have a 7600 and you need to replace everything but the chassis and PSUs to upgrade to higher speeds, does it make sense to do so, when there's already the ASR 9000 available? A much better router at presumably approx. the same production cost as a 7600 full of ES+. In my opinion, no. What they *could* easily do is support the 7600 chassis in the Catalyst 6500 software 15.0 SY. That I think they might, and there's kind of a poetic justice in it if they do, because everything would then be back to square one. Maybe, just because of that, they won't: It would look like they made a mistake when they split the two products ;-) (Hi Gert!) -A ___ 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] VS-S720-10G alternative
On Wednesday, June 13, 2012 03:35:21 PM adam vitkovsky wrote: > If Two 10G uplink ports isn't enough > ME 3600X 24CX has 4x10GigE - though it has other stuff > you won't need and it's a 2U unit and it's twice as > expensive as ME 3600x I would say: - Cisco ASR9001 - Juniper MX80 - Juniper MX240 (if space is an issue) Even Juniper's EX4500, while it will support MPLS, won't scale well in those scenarios either. 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] VS-S720-10G alternative
On Wednesday, June 13, 2012 02:00:38 PM scott owens wrote: > for those of you looking at the sup720-10G or 7k ( I have > sets of both of them as well ), take a look at Ciscos > new 4500X 1U 10G/1G switch/router. > > http://www.cisco.com/en/US/prod/collateral/switches/ps109 > 02/ps12332/data_sheet_c78-696791.html > > I think it might not work as a multi-provider BGP > solution but it is interesting enough that instead of a > pair of 7009s we are going to look at this, we may even > think about replacing one of our 7010 pairs ( VSS vs VPC > when you only have 1 VDC can be a fair trade ). With an > SFP+ ZR optic this can do just about anything an X2 or > XenPak 6704/6708/6716 could do. Loving the 4500-X's for core switching in small- to medium- sized PoP's. Pitching it against Juniper's EX4500 as well. Both support SFP and SFP+ on the same port, so makes upgrading to 10Gbps in the future a piece of cake. I'm done with the large chassis for the majority of core switching installations :-). 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] Me3600 microburst / drops / queue-limit
Hi Rick, This is a valid request. We'll be introducing this command in the future release. I don't have the exact release number but it is in the roadmap. Can you unicast me the customer name? Regards, Waris -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of sledge...@gmail.com Sent: Tuesday, June 19, 2012 1:37 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Me3600 microburst / drops / queue-limit I read a reply from Waris saying that microburst can cause drops when traffic arrives from high speed interfaces, he suggested increasing the queue-limit to 492 KB, the box only has a total of 44MB for packet buffer and I would like to monitor how much of this total is in use at any one time, is there an snmp oid that would show me this usage or any other way I can monitor this. Maybe One for Waris if he still monitors the list or anybody else who has come across this situation before. Thanks Rick ___ 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] ME3600X IOS Version
Faruk, Can you send me the SR number for the following issue? It should be fixed in 15.2(2)S too. Let me confirm the release and will get back to you. Regards, Waris -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Faruk Sejdic Sent: Monday, June 25, 2012 4:22 AM To: cisco-nsp@puck.nether.net Cc: cisco-nsp-requ...@puck.nether.net Subject: Re: [c-nsp] ME3600X IOS Version It's hard to say, we're still waiting for right release. :( We already tried all this versions but all of them have serious bugs. Even with new 15.2(2)S1 we hit a bug with Multicast Traffic Failure on EVC Interface In general, if you have EVC on interface configured with IPTV VLAN (mostly multicast traffic) and tried to add this EVC to an other interface multicast stops. Cisco TAC says this should be fixed in 15.2(4)S. :) Regards Faruk I'd recommend 15.2(2)S1. 15.1(2)EY is a branch release which probably won't have a long lifespan now that these switches have been integrated into mainline S code. 15.2(2)S1 has been solidly stable for us with the exception of what appears to be a cosmetic bug in that these messages are printed to the console: "Jun 25 17:10:02.164: %SFF8472-3-THRESHOLD_VIOLATION: Te0/2: Rx power high alarm; Operating value: 1.4 dBm, Threshold value: 0.0 dBm." I vaguely recall seeing a DDTS Caveat about this problem too. Otherwise all good, no other issuesand really like the hardware. Reuben On 25/06/2012 5:08 PM, Ivan wrote: > Hi, > > I know the ME3600X has come up quite a lot recently on this list, but > as far as I recall and can find, it has been a while since there have > been any comments regarding the "best/most stable" version. > > I am currently running 151-2.EY but will deploying some more hardware > shortly and would be interested what versions others are successfully > using, especially 15.2S or 15.2S1. 151-2.EY has been good so far but > I am aware of the rapid development on software for this platform and > also that there are quite a few issues around. ___ 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] m-vpn
On Monday, July 02, 2012 09:28:15 AM adam vitkovsky wrote: > Right the need to peer with every other PE in the mVPM > domain -but what would be the limitation on the PIM > adjacencies on modern PE boxes 1k maybe 2k? Well, obviously with increase in control and data plane resources, you can scale better, but it doesn't necessarily mean it's still a good solution. The reason I like NG-MVPN (or BGP-MVPN if you work at Juniper) is that, if you think about it carefully, it's a Unicast operation in the core. That lends itself well to the l3vpn concept, which is why it scales very well, decoupling control plane functions from data plane functions, unlike classic Rosen MVPN's. p2mp RSVP-TE and mLDP actually create Unicast LSP's, and the NG-MVPN infrastructure simply replicates traffic across those Unicast LSP's in a way that looks like Multicast (so- called branch routers, mid-point routers and bud routers). It has good scaling properties, especially if you're running mLDP. On Cisco platform like the CRS, even though the MPLS data plane signaling is Unicast in nature, it still takes advantage of the fabric replication architecture within the chassis itself, which is good. > Yes that would mostly apply in mVPN implementations for > VPLS, however you'd need PIM at both ends for L3 VPNs > where you are basically extending customer's m-cast > domain over the your MPLS core You only really need PIM on the Sender PE-to-Sender CE link. All customers connected to Receiver PE routers only need to support IGMP. But like I said, many operators run PIM on the Receiver PE routers anyway as well, since it enables IGMP automatically and simplifies global device configuration. BGP takes care of distribution of PIM data across the backbone, negating the need for PIM in the core. MPLS takes care of forwarding of Multicast traffic from Source to Receiver, negating the need for IP/GRE in the core. > Hahaha right with my comment I haven't meant it quite > like that :) My point was that BGP is being asked to do a lot. Some of it makes sense, some of it doesn't. I'm not deluded, but I appreciate a good solution when I see one :-). > That's great news, but still it would be great to see the > support for the 7200 -but I guess it's not going to > happen as they would like to force us to upgrade to > ASR1k You won't see it for the same reasons you didn't get VPLS on the 7200 platform. The most you'd ever see on the 7200 platform re: NG-MVPN would be MCAST-NLRI support if it's being used a route reflector (which is what happened also with the VPLS l2vpn NLRI on the same platform), but that's all you'll see. You'll need to invest in the ASR1000 or ASR9000 if you want full NG-MVPN capability, from Cisco. Hope this helps. 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] m-vpn
On Monday, July 02, 2012 09:05:20 AM adam vitkovsky wrote: > Last time I've looked at the m-cast configuration guide > for ASR9000 4.2 it had configuration examples for MLDP > with BGP -wouldn't that be the BGP-MVPN please? Do you have a link? Cisco already support carrying the RPF routes in BGP, but what we're referring to is carrying C-Multicast data in BGP. 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] m-vpn
> PIM in the global table may not be an issue, but mVPN-based PIM is a different story. Right the need to peer with every other PE in the mVPM domain -but what would be the limitation on the PIM adjacencies on modern PE boxes 1k maybe 2k? > You only need PIM at the edge where you're picking up the Source. Receiver PE routers only require IGMP Yes that would mostly apply in mVPN implementations for VPLS, however you'd need PIM at both ends for L3 VPNs where you are basically extending customer's m-cast domain over the your MPLS core > with the way the IETF are going, we shall soon see BGP carrying DNS. Hahaha right with my comment I haven't meant it quite like that :) > With IOS XE planning to support NG-MVPN soon That's great news, but still it would be great to see the support for the 7200 -but I guess it's not going to happen as they would like to force us to upgrade to ASR1k adam -Original Message- From: Mark Tinka [mailto:mark.ti...@seacom.mu] Sent: Sunday, July 01, 2012 11:07 PM To: cisco-nsp@puck.nether.net Cc: adam vitkovsky; 'Phil Bedard'; 'Christian' Subject: Re: [c-nsp] m-vpn On Monday, June 11, 2012 09:23:22 AM adam vitkovsky wrote: > I didn't came across any limitations/scalability issues running PIM to > distribute customer m-cast state did any of you please? PIM in the global table may not be an issue, but mVPN-based PIM is a different story. > I'm a fan of the idea to let BGP carry everything,... Well, I'm not (which is why I still prefer LDP-based EoMPLS over BGP-based EoMPLS), but it makes sense for Multicast. I always said, with the way the IETF are going, we shall soon see BGP carrying DNS. That's the point I'll hand in my RJ-45 jacks and crimping tool :-). > but I fail to see an added value here (maybe PIC-Edge for m-cast?) And > yet I'd still have to run PIM at the edge You only need PIM at the edge where you're picking up the Source. Receiver PE routers only require IGMP (although in operation, most folk would enable PIM anyway, as it automatically turns on IGMP). BGP is needed because the core doesn't run PIM. Without PIM in the core, you need a method to distribute Multicast state from Source to Receiver. > Also all this requires the upgrade of all the Intra/Inter AS RRs to > support the new SAFI One of the reasons we maintained Juniper route reflectors even though the Cisco's made sense. With IOS XE planning to support NG-MVPN soon, expect the ASR1001 (a favorite for route reflection, in my books), support for the MCAST-NLRI SAFI won't be an issue. > As far as the core signaling protocol is concerned MPLS-TE requires > much more state in the core than MLDP and I believe the trend now is > to go the IP FRR/LFA way instead of the complex MPLS-TE FRR leaving TE > only for exceptional cases where we really need to engineer traffic > paths and protect BW or temporary solutions till core link upgrades Juniper already support mLDP for BGP-MVPN's, but like I said before, it's the same old VPLS BGP vs. LDP war. Eventually, Cisco will cave, especially since Juniper support both. 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] m-vpn
Last time I've looked at the m-cast configuration guide for ASR9000 4.2 it had configuration examples for MLDP with BGP -wouldn't that be the BGP-MVPN please? adam -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mark Tinka Sent: Sunday, July 01, 2012 10:57 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] m-vpn On Friday, June 08, 2012 05:11:00 PM Christian wrote: > Juniper implements the most complicated way in my opinion. NG means > running BGP for auto-discovery, BGP for c-state advertisements *and* > pruning, and then RSVP-TE for LSP setup. > > What to do now? Both RFCs are from Juniper and Cisco, but both > implement totally different concepts, one bloated, the other a bit > proprietary (or not?). > > Is it now Cisco's fault that we don't have interoperability, because > they didn't want to implement the tainted BGP-way? There are so many > options and possibilities in the RFC to implement mVPN so that > interoperability is in either case very unlikely to happen for the > next years. > > How difficult can Multicast be? Should we wait another 10 years for > good solution? Cisco may huff and puff, but they will add support for BGP- MVPN's much like they did with BGP-based VPLS signaling on the ASR9000. Yes, adding PIM into BGP is awkward, but not having to run PIM in the core is a huge advantage (well, it was for us anyway - when the core was mostly old Juniper routers that needed Tunnel PIC's to run PIM, and even after the core was migrated to either Juniper MX or Cisco CRS routers, which don't need Tunnel PIC's to run PIM, it was still simpler not having to worry about PIM in the core). 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/
