[c-nsp] ME6524 dying

manderson chiefwfb at gmail.com
Tue Mar 15 11:35:22 EDT 2011 

Bernhard, did the SXI4 code rev fix the issue?  I'm getting ready to deploy
SXI5 so I have a vested intrest :-)




On Tue, Mar 15, 2011 at 8:20 AM, <cisco-nsp-request at puck.nether.net> wrote:

> Send cisco-nsp mailing list submissions to
>        cisco-nsp at puck.nether.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://puck.nether.net/mailman/listinfo/cisco-nsp
> or, via email, send a message with subject or body 'help' to
>        cisco-nsp-request at puck.nether.net
>
> You can reach the person managing the list at
>        cisco-nsp-owner at puck.nether.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cisco-nsp digest..."
>
>
> Today's Topics:
>
>   1. Re: Non-disruptive ISSU for Nexus 5000 (Brad Hedlund (brhedlun))
>   2. Re: sup2 VRRP/HSRP limits (Andrew Jones)
>   3. Re: load share eBGP and iBGP (Tony)
>   4. Re: Easy question about connecting LANs over WANs (Per Carlson)
>   5. ME6524 dying (Bernhard Schmidt)
>   6. Re: ME6524 dying (Ge Moua)
>   7. Small network Route Reflectors? (Peter Rathlev)
>   8. Re: Small network Route Reflectors? (David Barak)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 14 Mar 2011 23:25:52 -0500
> From: "Brad Hedlund (brhedlun)" <brhedlun at cisco.com>
> To: "Church, Charles" <Charles.Church at harris.com>
> Cc: nsp-cisco <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] Non-disruptive ISSU for Nexus 5000
> Message-ID: <991AAF45-9FDC-43DF-8404-FCADA93B5808 at cisco.com>
> Content-Type: text/plain;       charset="us-ascii"
>
> Hi Chuck,
>
> The switch not being upgraded will keep the vPC connections UP, just as you
> witnessed when your switch rebooted due to fan issues. However...
>
> Prior to the recent 5.0(2) release, IF your vPC connections were reset for
> some other reason (server rebooting) while you had one of your Nexus 5000s
> down for maintenance, your server vPC would not come back up. This is
> because the default behaviour is for the vPC primary switch to first check
> the vPC interface configuration is in sync with the secondary switch before
> allowing it come UP. If the secondary switch was down for maintenance you
> were SOL.
>
> In 5.0(2) a new "feature" was introduced called vPC Peer Config Check
> Bypass, which if configured, allows the vPC member ports to come UP even if
> the secondary switch is unavailable. The config check will happen after the
> secondary switch comes online, and if there is a mismatch only the new leg
> will be prevented while the existing leg continues to forward.
>
> Cheers,
>
> Brad Hedlund
> http://bradhedlund.com
> --
>
>
>
> On Mar 14, 2011, at 9:49 PM, "Church, Charles" <Charles.Church at harris.com>
> wrote:
>
> > Brad,
> >
> >    What is the consequence of doing a disruptive upgrade on one of the
> > 5010s or 5020s?  I've had a 5010 reboot due to a fan issue, with no
> server
> > connectivity lost due to the redundancy.  Will the one not being upgraded
> > keep its VPCs up, or will they go down for a bit while the other is
> > reloading?  I'm not too worried about any downstream FEX modules, but
> > keeping the VPCs up on 10 gig ports is what's important.
> >
> > Thanks,
> >
> > Chuck
> >
> > -----Original Message-----
> > From: Brad Hedlund (brhedlun) [mailto:brhedlun at cisco.com]
> > Sent: Sunday, March 13, 2011 10:53 PM
> > To: Church, Charles
> > Cc: nsp-cisco
> > Subject: Re: [c-nsp] Non-disruptive ISSU for Nexus 5000
> >
> > Hi Chuck,
> >
> > ISSU for Nexus 5000 is only supported when the switch is a Leaf on the
> > Spanning Tree, not a Root. That might be the case with your 5010s, but
> not
> > your 5020s.
> >
> > Reason for that is because there is a ~90 sec budget to restart the lone
> > control plane, and that is too long for a STP root not to be sending
> BPDUs
> > ;(
> >
> > BTW, you can make a trunk port an "Edge" with the interface command:
> > "spanning-tree port type edge trunk"
> >
> > Cheers,
> > Brad
> >
> >
> > Brad Hedlund
> > http://bradhedlund.com
> > --
> >
> >
> > On Mar 13, 2011, at 8:13 PM, "Church, Charles" <
> Charles.Church at harris.com>
> > wrote:
> >
> >> All,
> >>
> >>   I'm having a hard time getting a non-disruptive upgrade to happen on
> >> my Nexus 5010s and 5020s.  I'd really like to have non-disruptive, as
> > we've
> >> got SAN attached Windows servers which tend to blue screen if they're
> > unable
> >> to reach their iSCSI disks across the Nexus devices for more than a
> couple
> >> seconds.  The topology has a pair of 5020s peered together, with a
> >> downstream 5010 pair peered together.  The NetApp SAN is a VPC off the
> >> 5020s, and the servers are multiple VPCs (one for each enclosure) off
> the
> >> 5010s.  There are no redundant links, all VPCs.  All ports on the 5010s
> > and
> >> 5020s are designated forwarding.  The connections into the SAN and
> servers
> >> are trunks, thus not really able to fall into the 'edge' category needed
> > for
> >> a non-disruptive ISSU.  It seems a trunk can't be an edge port, even if
> it
> >> should be.  Since I've got no redundant links, should I consider
> disabling
> >> spanning tree all together until the upgrade is complete?  I've got
> >> redundancy into all chassis, so the loss of one switch doing a
> > 'disruptive'
> >> upgrade is ok, but my concern is the peer switch will drop the VPCs as
> > well
> >> (like when you've got temporarily-mismatching things like QoS, etc).
>  Any
> >> other way to consider?
> >>
> >> Thanks,
> >>
> >> Chuck Church
> >> Network Planning Engineer, CCIE #8776
> >> Southcom
> >> Harris IT Services
> >> 1210 N. Parker Rd.
> >> Greenville, SC 29609
> >> Office: 864-335-9473
> >> Cell: 864-266-3978
> >> E-mail: charles.church at harris.com
> >> Southcom E-mail: charles.church.ctr at hq.southcom.mil
> >>
> >> _______________________________________________
> >> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/cisco-nsp
> >> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 15 Mar 2011 16:12:28 +1100
> From: Andrew Jones <aj at jonesy.com.au>
> To: Mack McBride <mack.mcbride at viawest.com>
> Cc: Cisco NSP <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] sup2 VRRP/HSRP limits
> Message-ID: <c3e0c88cf5d63ef6fe82556ec9a30547 at localhost>
> Content-Type: text/plain; charset=UTF-8
>
> Thanks Mack,
> Does anyone have an information on how many interfaces running HSRP could
> be configured on a sup2 before the load would become unworkable?
> Thanks,
> Andrew
>
> On Tue, 8 Mar 2011 10:53:07 -0800, Mack McBride <mack.mcbride at viawest.com>
> wrote:
> > Different code trains have different limits on HSRP sessions.
> > This is in addition to what may be imposed for different Supervisor
> > engines.
> > If you have too many for the supervisor load they will become unstable.
> >
> > Mack McBride
> > Network Architect
> >
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Andrew Jones
> > Sent: Monday, March 07, 2011 5:48 PM
> > To: Cisco NSP
> > Subject: [c-nsp] sup2 VRRP/HSRP limits
> >
> > Hi All,
> > What is the maximum number of VRRP groups which can be configured on a
> > 6500/sup2? I've found that the limit for HSRP seems to be 256. Do these
> > limits increase on the SUP720-3BXL?
> >
> > I'm trying to use a pair of 6500s as the default gateway for a couple of
> > thousand VLANs, and am looking at options for redundancy.
> > Thanks,
> > Andrew
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 14 Mar 2011 23:04:22 -0700 (PDT)
> From: Tony <td_miles at yahoo.com>
> To: cisco-nsp at puck.nether.net, "Oliver Boehmer \(oboehmer\)"
>        <oboehmer at cisco.com>
> Subject: Re: [c-nsp] load share eBGP and iBGP
> Message-ID: <966732.41472.qm at web110108.mail.gq1.yahoo.com>
> Content-Type: text/plain; charset=utf-8
>
>
>
> --- On Mon, 14/2/11, Oliver Boehmer (oboehmer) <oboehmer at cisco.com> wrote:
>
> > From: Oliver Boehmer (oboehmer) <oboehmer at cisco.com>
> > Subject: RE: [c-nsp] load share eBGP and iBGP
> > To: "Tony" <td_miles at yahoo.com>, cisco-nsp at puck.nether.net
> > Received: Monday, 14 February, 2011, 6:35 PM
> >
> > > We have a PE router that terminates a DSL session from
> > two CE routers,
> > R1 &
> > > R2. R1 & R2 are at the same location and share the
> > same LAN network.
> > >
> > > R1 is the default gateway for the network at this
> > location and I want
> > it to
> > > do load sharing on both of the links (ie. the one from
> > R1 and also
> > R2). I'm
> > > aware of the problems/issues that can/may arise, but
> > this is what
> > would like
> > > to be done.
> >
> >
> > If you go down the "turn ibgp to ebgp using local-as" route
> > and use ebgp
> > multipath, I guess you also need "bgp bestpath as-path
> > multipath-relax"
> > to compare ebgp paths with different as-path
> >
>
> Just a quick follow up, been too busy/lazy to get back sooner.
>
> I used "bgp bestpath as-path multipath-relax" along with making both of the
> paths the same AS length and it is working as I would like now.
>
> Thanks,
> Tony.
>
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 15 Mar 2011 08:57:23 +0100
> From: Per Carlson <pelle at hemmop.com>
> To: cisco-nsp <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] Easy question about connecting LANs over WANs
> Message-ID:
>        <AANLkTi=dP4KhcE2hroRa5zhs1hw8Qgqg_w4D2uwCb6G6 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> > What is the best way to do this? ?GRE tunnel? ?Will DHCP go across it?
>
> You need something that works on Layer2, GRE is a Layer3 thing. You
> could try L2TPv3 Local Switching:
>
> http://www.cisco.com/en/US/docs/ios/wan/configuration/guide/wan_l2_tun_pro_v3_ps10592_TSD_Products_Configuration_Guide_Chapter.html#wp1755302
>
> --
> Pelle
>
> RFC1925, truth 11:
> ?Every old idea will be proposed again with a different name and
> ?a different presentation, regardless of whether it works.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 15 Mar 2011 14:38:58 +0000 (UTC)
> From: Bernhard Schmidt <berni at birkenwald.de>
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] ME6524 dying
> Message-ID: <ilntm2$dr3$1 at dough.gmane.org>
>
> Hi,
>
> we have a ME6524-GT series in a remote location that keeps dying on us
> every couple of weeks. Symptoms are:
>
> * All routing protocols and LLDP time out on our side
> * Physically the box looks fine, Status LED and even the link LEDs are
>  still green
>  - I cannot really say something about the physical link status, since
>    the link in question does not forward link-state to our side
> * Console is dead, no reaction at all
>  - we do not have any OOB equipment on location yet, so I cannot tell
>    whether it emitted a dying gasp
> * CPU, Memory, all look normal up to five minutes before the crash
> * remote syslog is enabled, nothing visible in it
> * no crashdump on any file system
> * looks fine after power cycle, no warnings anywhere
>
> The box is not doing much at all, OSPFv2/v3, MPLS LDP and BGP towards
> our core and one partial transit, maybe 4000 prefixes, 200 Mbps of
> traffic.
>
> Up to now we have been running 12.2(33)SXI5 Adv.IP non-modular, I have
> now downgraded to SXI4.
>
> This is my first Cisco ever that isn't even accessible on the console
> anymore when it crashes. Has anyone seen something similar?
>
> Best Regards,
> Bernhard
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 15 Mar 2011 09:54:32 -0500
> From: Ge Moua <moua0100 at umn.edu>
> To: Bernhard Schmidt <berni at birkenwald.de>, cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ME6524 dying
> Message-ID: <4D7F7DA8.6070408 at umn.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> we've got similar boxes at a few large remote sites doing similar
> functionality as yours, and these run pretty rock solid with the
> exception of running into a few IOS bugs here & there:
>
> "sh inv"
> NAME: "ME-C6524GS-8S", DESCR: "Cisco Systems Catalyst 6500 1.5 RU
> virtual Chassis System"
> PID: ME-C6524GS-8S     ,                     VID: V03, SN: CAT1203C01Y
>
>
> --
> Regards,
> Ge Moua
>
> Network Design Engineer
> University of Minnesota | OIT - NTS
> --
>
>
> On 3/15/11 9:38 AM, Bernhard Schmidt wrote:
> > Hi,
> >
> > we have a ME6524-GT series in a remote location that keeps dying on us
> > every couple of weeks. Symptoms are:
> >
> > * All routing protocols and LLDP time out on our side
> > * Physically the box looks fine, Status LED and even the link LEDs are
> >    still green
> >    - I cannot really say something about the physical link status, since
> >      the link in question does not forward link-state to our side
> > * Console is dead, no reaction at all
> >    - we do not have any OOB equipment on location yet, so I cannot tell
> >      whether it emitted a dying gasp
> > * CPU, Memory, all look normal up to five minutes before the crash
> > * remote syslog is enabled, nothing visible in it
> > * no crashdump on any file system
> > * looks fine after power cycle, no warnings anywhere
> >
> > The box is not doing much at all, OSPFv2/v3, MPLS LDP and BGP towards
> > our core and one partial transit, maybe 4000 prefixes, 200 Mbps of
> > traffic.
> >
> > Up to now we have been running 12.2(33)SXI5 Adv.IP non-modular, I have
> > now downgraded to SXI4.
> >
> > This is my first Cisco ever that isn't even accessible on the console
> > anymore when it crashes. Has anyone seen something similar?
> >
> > Best Regards,
> > Bernhard
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 15 Mar 2011 16:07:36 +0100
> From: Peter Rathlev <peter at rathlev.dk>
> To: cisco-nsp <cisco-nsp at puck.nether.net>
> Subject: [c-nsp] Small network Route Reflectors?
> Message-ID: <1300201656.18247.133.camel at abehat.dyn.net.rm.dk>
> Content-Type: text/plain; charset="UTF-8"
>
> We're thinking about introducing dedicated Route Reflectors in our
> small-ish MPLS VPN network. We currently have ~35 PE devices, all
> 6500/Sup720. There are no dedicated P devices.
>
> A couple of the PEs are RRs currently, but given the slow RP on a Sup720
> we'd like dedicated RRs instead; and there are many other good reasons
> for that of course.
>
> We're talking ~10k MP-BGP routes now (plus about ~100 IGP routes
> (IS-IS)) with per-PE RDs.
>
> The ISR 2901 seems fit for the job. Any comments on that? Are there
> other devices better suited, assuming we intend to buy something brand
> new?
>
> According to FN the ISR 2901 IP Base image doesn't support MPLS, but
> otherwise supports all we need, i.e. IS-IS and MP-BGP. MPLS forwarding
> isn't a problem since the RR isn't supposed to forward traffic. Any good
> reasons to choose something other than IP Base?
>
> Thanks.
>
> --
> Peter
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 15 Mar 2011 08:20:17 -0700 (PDT)
> From: David Barak <thegameiam at yahoo.com>
> To: Peter Rathlev <peter at rathlev.dk>, cisco-nsp
>        <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] Small network Route Reflectors?
> Message-ID: <673705.61545.qm at web31807.mail.mud.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> ________________________________
> From: Peter Rathlev <peter at rathlev.dk>
> >The ISR 2901 seems fit for the job. Any comments on that? Are there
> >other devices better suited, assuming we intend to buy something brand
> >new?
>
> >According to FN the ISR 2901 IP Base image doesn't support MPLS, but
> >otherwise supports all we need, i.e. IS-IS and MP-BGP. MPLS forwarding
> >isn't a problem since the RR isn't supposed to forward traffic. Any good
> >reasons to choose something other than IP Base?
>
>
> Make sure that the image you're looking at supports all of the
> address-families
> you need: for instance, MDT address-family is not supported on many images.
>
> David Barak
> Need Geek Rock? Try The Franchise:
> http://www.listentothefranchise.com
>
>
>
>
> ------------------------------
>
> _______________________________________________
> cisco-nsp mailing list
> cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
>
> End of cisco-nsp Digest, Vol 100, Issue 37
> ******************************************
>

More information about the cisco-nsp mailing list