Re: [c-nsp] 3750G-48 / 12.2(58)SE1 issue (word of warning)
Hi Jeff, This seems to be caused by CSCsu83001 and CSCsv11710. This is fixed in 12.2(50)SE, however if you upgrade the switch from older versions, you will see this problem. I understand you did an upgrade to 12.2(58)SE1, but if you had older versions running on the switches, you will face this issue. The solution is to remove the "snmp ifmib ifindex persist" configuration from the switch prior to the upgrade, because the old version uses a different structure and after the upgrade, it will still use the original structure. Also, make sure you don't have "snmp-server ifindex persist" in your configuration, because it's not supported. The switch will retain physical interfaces ifindex after upgrade even without this configuration item as physical interfaces use pre-defined index based on the switch number and type of interface. Best regards, Andras On Sat, May 21, 2011 at 8:42 PM, Jeff Kell wrote: > We had a "need" (bugfix) to upgrade our 12.2(55)SE1 stack of 4 * > 3750G-48s to 12.2(58)SE1 (IP Services). The maintenance window was last > night, and appeared to go well, until the phone lit up... > > To make a very long story as short as possible, to the best extent I can > figure it out... > > The stack is running several VRFs, incoming traffic from the core > arriving on a 4-port cross-stack etherchannel trunk carrying multiple > vlans (one per VRF), with connectivity to the edge (default) out of the > core to our border routers. All traffic (in-house as well as default) > traverses the same trunks. IGP on the VRFs is EIGRP in all cases. > > The borders lit up after the upgrade hitting reverse-path verify on our > ASAs. Two of the VRFs were showing traffic from "other" VRFs where they > should never be seen. > > It appears that ingress traffic on one vlan was landing on another > (and/or else egress traffic on one vlan was landing on another). The > "crossed-plumbing" was exactly two pairs out of a possible 12, with > improper egress resulting on 2 destination vlans. Everything else was fine. > > If I shutdown the SVIs of the two problem vlans, everything worked fine > again (the "other two" vlans of the pair then routed correctly). > > I checked default routes, CEF adjacencies, everything I could think > could be affecting things, but if either of the problem SVIs was brought > back up, the mess ensued again. > > Rebooting the stack resulted in no change (well, actually, only one pair > was crossed initially, the second pair appeared after the second reboot). > > Reloaded 12.2(55)SE1, brought the two SVIs back up, all was fine. > > Still scratching my head. I also applied 12.2(58) to a 3750E and 3750X > stack during the same window, no issues, very similar configuration and > adjacencies. > > So for the 3750G platform, you might hold off, or at least cautiously > approach this update. I have a TAC case on this one but it may be a > tough one to reproduce (I certainly don't want to repeat it here!). > > The only "anomaly" during the update was the appearance of the following > errors during the reload (same 4 appeared in each of the 4 member's > startup logs): > >> *Mar 1 00:04:14.938: %STACKMGR-4-SWITCH_ADDED: Switch 1 has been >> ADDED to the stack >> *Mar 1 00:04:14.938: %STACKMGR-4-SWITCH_ADDED: Switch 2 has been >> ADDED to the stack >> *Mar 1 00:04:14.938: %STACKMGR-4-SWITCH_ADDED: Switch 3 has been >> ADDED to the stack >> *Mar 1 00:04:14.938: %STACKMGR-4-SWITCH_ADDED: Switch 4 has been >> ADDED to the stack >> *Mar 1 00:04:15.248: platform assert failure: hwidb->snmp_if_index == >> ifIndex: ../src-hulc/src-common/hpm_idbman.c: 1843: >> hpm_register_idb_with_snmp >> *Mar 1 00:04:15.248: -Traceback= 229B110z 16AEC38z 184DBA8z 184F040z >> 184E298z 184D340z 1864174z 1832F7Cz 16B6824z 3112CECz 3112D90z >> 3112EF8z 22A6F50z 22A721Cz 1CC0FA8z 1CBAE1Cz >> *Mar 1 00:04:15.340: platform assert failure: hwidb->snmp_if_index == >> ifIndex: ../src-hulc/src-common/hpm_idbman.c: 1843: >> hpm_register_idb_with_snmp >> *Mar 1 00:04:15.340: -Traceback= 229B110z 16AEC38z 184DBA8z 184F040z >> 184E298z 184D340z 1864174z 1832F7Cz 16B6824z 3112CECz 3112D90z >> 3112EF8z 22A6F50z 22A721Cz 1CC0FA8z 1CBAE1Cz >> *Mar 1 00:04:15.407: platform assert failure: hwidb->snmp_if_index == >> ifIndex: ../src-hulc/src-common/hpm_idbman.c: 1843: >> hpm_register_idb_with_snmp >> *Mar 1 00:04:15.416: -Traceback= 229B110z 16AEC38z 184DBA8z 184F040z >> 184E298z 184D340z 1864174z 1832F7Cz 16B6824z 3112CECz 3112D90z >> 3112EF8z 22A6F50z 22A721Cz 1CC0FA8z 1CBAE1Cz >> *Mar 1 00:04:15.491: platform assert failure: hwidb->snmp_if_index == >> ifIndex: ../src-hulc/src-common/hpm_idbman.c: 1843: >> hpm_register_idb_with_snmp >> *Mar 1 00:04:15.491: -Traceback= 229B110z 16AEC38z 184DBA8z 184F040z >> 184E298z 184D340z 1864174z 1832F7Cz 16B6824z 3112CECz 3112D90z >> 3112EF8z 22A6F50z 22A721Cz 1CC0FA8z 1CBAE1Cz > > I thought that might have been the "smoking gun", but the same 4 errors > appeared during startup after reverting b
Re: [c-nsp] off-topic NMS Suggestion
On 18.05.2011 16:47, Jason Gurtz wrote:
> licensing issues. If it were a free or open source application this would
> be expected. In the commercial world, a bit more polish is expected of a
> $30K piece of software. Make sure you budget for this kind of time or
> level of support if you go there.
Wow ... paying 30k and not even able to do the basic admin yourself? At
prices like that, you could go full commercial support contract on
OpenNMS, and have a true enterprise-grade NMS, while being able to get
all the basic and advanced stuff done yourself ... and not worry about
system performance every time you add a couple nodes ... ("expecting"
higher cost for maintenance on Open Source software is pretty
prejudicial IMHO...)
-garry
___
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 IPv6 with IS-IS in NX-OS
In the case of the ME3800X its a new platform but the nexus is three years old and it have ipv6 from the begining but for some reason they didnt integrate these two new TLV. On Sun, May 22, 2011 at 19:55, Mark Tinka wrote: > On Sunday, May 22, 2011 08:53:01 PM Nitzan Tzelniker wrote: > > > If you miss this information and running ipv6 with IS-IS > > as your IGP NX-OS currently doesn't support ipv6 over > > IS-IS (rfc5308). > > Well, neither does the ME3600X/3800X nor do many of the low- > end desktop switches that support IS-IS for IPv4. > > This is a case of waiting for the software to catch up. We > don't run the Nexus platform, but I'd suggest pushing your > account team to get this integrated for you. > > Cheers, > > 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] Routing IPv6 with IS-IS in NX-OS
On Sunday, May 22, 2011 08:53:01 PM Nitzan Tzelniker wrote: > If you miss this information and running ipv6 with IS-IS > as your IGP NX-OS currently doesn't support ipv6 over > IS-IS (rfc5308). Well, neither does the ME3600X/3800X nor do many of the low- end desktop switches that support IS-IS for IPv4. This is a case of waiting for the software to catch up. We don't run the Nexus platform, but I'd suggest pushing your account team to get this integrated for you. 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] Open Source netflow recommendations
On Saturday, May 21, 2011 12:09:49 AM Nick Hilliard wrote: > Difficult to understand why an MS-DPC is required for > jflow v9. The additional overhead of netflowv9 is very > low, and the actual cost of running an MS-DPC can be > quite high (i.e. extra slot which would otherwise be > used for a traffic blade). $$ :-). Well, both Cisco and Juniper have introduced "additional" services over new line cards (or service cards, whatever you'd like to call them), but Juniper have been a little over-zealous with this since they opened shop. Think of the Tunnel PIC. Think of NAT. I do believe that service cards are not all bad as they can be useful to offload certain services in order to let them scale, but Juniper's pervasive use of these for even simple things like Netflow export, NAT or Tunneling (well, until the MX-series, of course re: tunneling) is just too much. 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] Open Source netflow recommendations
On Friday, May 20, 2011 05:12:44 PM Saku Ytti wrote: > What features do you mean specifically? As far as I know, > only difference MIC have is ability to do HQoS. And even > this I think is just software thing, can't see why the > chassis ports couldn't do HQoS too. Lack of H-QoS in the MX80 fixed chassis is one problem, as well as SyncE + friends. Can't get into too much detail here, but it's all stuff your Juniper SE can tell you :-). We are researching new peering routers and found out (at the time) that hardware-based Netflow isn't supported in the MX80. I haven't checked since then, so not sure what the plan there is. 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/
[c-nsp] Routing IPv6 with IS-IS in NX-OS
If you miss this information and running ipv6 with IS-IS as your IGP NX-OS currently doesn't support ipv6 over IS-IS (rfc5308). I would like to hear a workaround for this limitation (6PE,OSPFv3). Thanks Nitzan ___ 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] Eric Magutu, CAPM wants to stay in touch on LinkedIn
Decline Sent from my iPhone On May 22, 2011, at 8:02 AM, "Eric Magutu, CAPM" wrote: > LinkedIn > > > > I'd like to add you to my professional network on LinkedIn. > > - Eric Magutu, CAPM > > Eric Magutu, CAPM > Senior Network Administrator at Safaricom > Kenya > > Confirm that you know Eric Magutu, CAPM > https://www.linkedin.com/e/-bfctb5-gnzxu0hu-62/isd/2959671663/DpeUenmI/ > > > > -- > (c) 2011, LinkedIn Corporation > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] Eric Magutu, CAPM wants to stay in touch on LinkedIn
LinkedIn I'd like to add you to my professional network on LinkedIn. - Eric Magutu, CAPM Eric Magutu, CAPM Senior Network Administrator at Safaricom Kenya Confirm that you know Eric Magutu, CAPM https://www.linkedin.com/e/-bfctb5-gnzxu0hu-62/isd/2959671663/DpeUenmI/ -- (c) 2011, LinkedIn Corporation ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
