Re: [c-nsp] Nexus 7K NX-OS Upgrade

[Alexander Lim]

Hi Charles,

I thought redundant sup is required for ISSU?

Regards,
Alexander Lim

On 8 Nov, 2012, at 8:50 AM, Charles Spurgeon  
wrote:

> While doing some more testing this aft I also removed the sup from
> slot 5 and did a "disruptive" single sup ISSU upgrade from 5.1(5) to
> 5.2(7) on the slot 6 sup without issues.
> 
> -Charles
> 
> On Tue, Nov 06, 2012 at 11:48:35PM +, Antonio Soares wrote:
>> Great, I must confess that I searched a lot and I didn't find this bug. So I
>> suppose the install all script will work well this time. I will come back to
>> the list next week with the good news. I hope :)
>> 
>> 
>> Thanks.
>> 
>> Regards,
>> 
>> Antonio Soares, CCIE #18473 (R&S/SP)
>> amsoa...@netcabo.pt
>> http://www.ccie18473.net
>> 
>> 
>> 
>> -Original Message-
>> From: Tóth András [mailto:diosbej...@gmail.com] 
>> Sent: terça-feira, 6 de Novembro de 2012 23:35
>> To: Antonio Soares
>> Cc: cisco-nsp
>> Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade
>> 
>> Hi Antonio,
>> 
>> In general, doing a traditional upgrade (changing boot variables) will not
>> update the BIOS for example, while an ISSU does and it's non-disruptive with
>> dual-supervisors.
>> 
>> There's a defect which caused the behavior you were seeing, CSCtn61286 which
>> affects 5.1(3). Since you were upgrading from that version, it was still
>> impacting the upgrade process. It has been fixed in 5.1(4) and 5.2(1)
>> already, so upgrading from 5.2(3a) to 5.2(7) will not have the same issue.
>> 
>> http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fet
>> chBugDetails&bugId=CSCtn61286
>> 
>> 
>> If the boot variables are incorrect, you can edit them as you'd do on an IOS
>> device, make sure you update the kickstart and system as well.
>> 
>> Upgrading from 5.2(3a) to 5.2(7) can be done using the install all
>> (ISSU) method.
>> 
>> Best regards
>> 
>> On Tue, Nov 6, 2012 at 11:38 AM, Antonio Soares  wrote:
>>> Hello group,
>>> 
>>> 
>>> 
>>> Anyone knows the difference between using the install all script or 
>>> just update the boot system flash command when upgrading NX-OS on a Nexus
>> 7K ?
>>> 
>>> 
>>> 
>>> The question applies to a single supervisor setup.
>>> 
>>> 
>>> 
>>> The official documentation mentions the two ways of doing it:
>>> 
>>> 
>>> 
>>> - using the install all script:
>>> 
>>> 
>>> 
>>> http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/upgra
>>> de/gui 
>>> de/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Guid
>>> e__Rel
>>> ease_5.x_chapter_00.html#con_314241
>>> 
>>> 
>>> 
>>> - using the traditional procedure:
>>> 
>>> 
>>> 
>>> http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/upgra
>>> de/gui 
>>> de/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Guid
>>> e__Rel
>>> ease_5.x_chapter_00.html#task_39E26688E1204F8CAAE876450A575E73
>>> 
>>> 
>>> 
>>> I had a bad experience in the past with the install all script. I was 
>>> doing an upgrade to a 7010 with only 1 supervisor that was installed in
>> slot 6.
>>> The install all script has a problem, may a bug, it only correctly 
>>> updates the boot variables for slot 5:
>>> 
>>> 
>>> 
>>> boot kickstart bootflash:/n7000-s1-kickstart.5.2.3a.bin sup-1
>>> 
>>> boot system bootflash:/n7000-s1-dk9.5.2.3a.bin sup-1
>>> 
>>> boot kickstart bootflash:/n7000-s1-kickstart.5.1.3.bin sup-2
>>> 
>>> 
>>> 
>>> The install all script assumes that if there is only one supervisor, 
>>> it should be on slot 5. Above we can see that the boot system is 
>>> missing for sup-2.
>>> 
>>> 
>>> 
>>> In summary, is there any problem if I simply update the boot variables 
>>> and reload ? May I end up with the supervisor running the new NX-OS 
>>> release and the modules the old NX-OS release ?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Regards,
>>> 
>>> 
>>> 
>>> Antonio Soares, CCIE #18473 (R&S/SP)
>>> amsoa...@netcabo.pt
>>> 
>>> http://www.ccie18473.net <http://www.ccie18473.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/
>> 
>> 
>> ___
>> 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] Nexus 7K NX-OS Upgrade

[Alexander Lim]

Hi Pete,

Do you know what caused the 3 secs blip? How can Cisco claims that it is 
non-disruptive then?
Thanks for sharing. 

Regards,
Alexander Lim

On 7 Nov, 2012, at 12:12 PM, Pete Templin  wrote:

> On 11/6/12 3:35 PM, Tóth András wrote:
>> Hi Antonio,
>> 
>> In general, doing a traditional upgrade (changing boot variables) will
>> not update the BIOS for example, while an ISSU does and it's
>> non-disruptive with dual-supervisors.
> 
> Just to add a data point, it's almost non-disruptive.  There's a noticeable 
> blink on a per-linecard basis, probably <3 seconds, but I've had to deal with 
> explaining the blip during a "non-disruptive" upgrade.
> 
> pt
> 
> 
> ___
> 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] Catalyst 6509 EOS/EOL

[Alexander Lim]

I am afraid you cannot renew the maintenance agreement for EoL product. Read 
this:
http://www.cisco.com/en/US/products/products_end-of-life_policy.html. 

Regards,
Alexander Lim

On 14 Sep, 2012, at 10:12 PM, Jon Lewis  wrote:

> On Thu, 13 Sep 2012, Antonio Soares wrote:
> 
>> Hello group,
>> 
>> The EOS/EOL announcement for the WS-C6509 says that the last Date of Support
>> is November 30, 2012:
> 
> You already can't buy a new support contract on a 6509 chassis.  Cisco 
> apparently expects us to junk those and replace them with 6509E chassis.
> 
>> But in the other hand, the Service Contract Center shows me the date of
>> 31-Dec-2015. Here's an example:
> 
> Maybe you can keep renewing an existing contract until 2015?
> 
> --
> Jon Lewis, MCP :)   |  I route
> Senior Network Engineer |  therefore you are
> Atlantic Net|
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
> ___
> 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] Catalyst 6509 EOS/EOL

[Alexander Lim]

AFAIK, the maintenance agreement is tied to the chassis, not the module. 

Regards,
Alexander Lim

On 13 Sep, 2012, at 11:04 PM, "Antonio Soares"  wrote:

> Hello group,
> 
> The EOS/EOL announcement for the WS-C6509 says that the last Date of Support
> is November 30, 2012:
> 
> http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_end-of
> -life_notice0900aecd8035ece4.html
> 
> But in the other hand, the Service Contract Center shows me the date of
> 31-Dec-2015. Here's an example:
> 
> Product Id  Serial Number / PAK Number  Installed-At Site  Product Label
> Product Status  Begin Date  End Date  End of Support  PO/MPO  SO/MSO  
> WS-C6509  XXX    ACTIVE   01-Feb-2012   30-Nov-2012
> 31-Dec-2015   XXX/   XXX/
> 
> And I have more 6509's showing exactly the same thing.
> 
> Does anybody know if there was any update to the original EOS/EOL
> announcement ? I don't find anything about it.
> 
> If the 2012 date is correct, what worries is what will happen to all the
> modules/supervisors that are not EOS/EOL but that are associated with a
> chassis that will be this year. Can we still open an RMA for it do I need to
> move them to a 6500-E ? How are you guys dealing with these issues ?
> 
> 
> Thanks.
> 
> Regards,
> 
> Antonio Soares, CCIE #18473 (R&S/SP)
> amsoa...@netcabo.pt
> http://www.ccie18473.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/

___
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] Dual Planar Core Design

[Alexander Lim]

Guys,

Do you know if there is any reference for dual planar core network design out 
there?
I came to know about this from cisco live session BRKRST-3365 "the evolution of 
the next generation network"

Thanks. 

Regards,
Alexander Lim

___
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] Dom and Non-Dom SFP Compatibility

[Alexander Lim]

According to Cisco SE that I asked, both are compatible. But I haven't tried it 
myself. 

Regards,
Alexander Lim

On Jul 9, 2012, at 7:24 PM, "Steve McCrory"  wrote:

> Guys,
> 
> 
> 
> Are there any known compatibility issues if I used a mixture of DOM and
> Non-DOM SFPS on either end of a fibre?
> 
> 
> 
> I need to cross link an ASR with a 7200 and only have an SPF-GE-S and an
> GLC-SX-MM in stock. Am I likely to encounter any issues using different
> SFPs on each end?
> 
> 
> 
> Cheers
> 
> 
> 
> Steven
> 
> 
> 
> Steven McCrory
> 
> Network Specialist
> 
> 
> 
> GCI Com
> 
> Unit 2
> 
> Modwen Road
> 
> Salford
> 
> M5 3EZ
> 
> 
> 
> Office:  0844 443 3537
> 
> Fax:  0844 443 3540
> 
> www.gcicom.net
> <https://mail.ipi-group.co.uk/exchweb/bin/redir.asp?URL=http://www.gcico
> m.net/> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Steve McCrory
> Senior Network Engineer
> 
> GCI Com
> Cedar Court Office Park
> Denby Dale Road
> Calder Grove
> Wakefield
> WF4 3QZ
> 
> Office:   0844 443 3537
> Fax:  0844 443 3540
> http://www.gcicom.net/
> 
> 
> This email has been swept by Webroot for viruses. Any files transmitted with 
> it are confidential and intended solely for the email recipient. If you are 
> not the intended recipient please delete this email immediately. Be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information is prohibited. If you have received this email in error please 
> notify the system administrator. Please note that any views or opinions 
> presented in this email are solely those of the author and do not necessarily 
> represent those of the company. Finally, the recipient should check this 
> email and any attachments for the presence of viruses.
> 
> 
> GCI Com incorporates the following Group Companies:
> GCI Telecom Group Limited Reg. No. 5396496, Edge Telecommunications Ltd Reg. 
> No. 5748740, Edge Telecom Ltd Reg. No. 3101247, IP Infrastructures Ltd Reg. 
> No. 4657026, Invomo Ltd Reg. No. 6267056, NetServices UK Ltd Reg. No. 
> 7118768, WAN Services Ltd Reg. No. 4082862. All Registered in England and 
> Wales, Registered Office: Global House, 2 Crofton Close, Lincoln, LN3 4NT
> ___
> 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] IP SLA configuration

[Alexander Lim]

Yeah, Data license. 

Regards,
Alexander Lim

On May 26, 2012, at 7:19 AM, chris  wrote:

> You need an additional license for that feature
> On May 25, 2012 7:18 PM, "Michael Malitsky"  wrote:
> 
>> I know I shouldn't be trying anything new at the end of Friday before a
>> long weekend, but...
>> 
>> I am trying to configure IP SLA to track a static route.  2821 router,
>> IOS 15.1.4(M)4, IP Base license.  First time I am trying to do this on
>> 15.1.  Previous experience and TAC documentation say IP SLA gets
>> configured with the "ip sla operation-number", etc.  I don't have that
>> option:
>> 
>> obmsc-bill-edge1(config)#ip sla ?
>> key-chain  Use MD5 Authentication for IP SLAs Control Messages
>> responder  Enable IP SLAs Responder
>> server IPPM server configuration
>> 
>> Can someone clue me in please?
>> 
>> Sincerely,
>> Michael
>> 
>> 
>> ___
>> 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 Nexus 5548UP w/Fibre Channel

[Alexander Lim]

Reset/reload of N5K is very fast right?

Regards,
Alexander Lim

On May 25, 2012, at 5:21 AM, Asbjorn Hojmark - Lists  wrote:

> On Thu, 24 May 2012 20:30:40 +, you wrote:
> 
>> I'm wondering if anyone has any experience/tips/advice when running
>> Fibre Channel on the Nexus 5548UP platform.
> 
> Yeah, we have customers doing that and do that ourselves.
> 
>> I've done a little bit of research, and understand that the FC ports
>> have to start at the back end of the chassis, and that to switch a
>> port from Ethernet mode over to FC mode, you need to reload the whole
>> switch.
> 
> Yeah, currently the ports have to be contiguous, and with FC at the
> high end. If you use a module, you don't have to reload the whole
> switch when changing the configuration. You can just reset the module.
> When running FCoE, you don't have to reset/reload anything.
> 
> To me, FC and FCoE on the N5000s is pretty mature and absolutely
> production ready.
> 
> -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] Stacking 3750X vs diverse 4948E

[Alexander Lim]

I think Nexus 5500 series support L3. 

Regards,
Alexander Lim

On May 20, 2012, at 12:54 PM, Skeeve Stevens  
wrote:

> Feature / Nexus 5010 / 3750X
> 
> VLANs / 507 / 1005
> MAC / 16k / 4k-12k
> L3 / N / Y
> vPC / Y / N
> 
> Nexus 5010 - less VLANs, no Layer 3, vPC
> 3750X - more VLAN, Layer 3, no vPC
> 
> 
> *Skeeve Stevens, CEO*
> eintellego Pty Ltd
> ske...@eintellego.net ; www.eintellego.net <http://www.eintellego.net.au>
> 
> Phone: 1300 753 383 ; Fax: (+612) 8572 9954
> 
> Cell +61 (0)414 753 383 ; skype://skeeve
> 
> facebook.com/eintellego
> 
> twitter.com/networkceoau ; www.linkedin.com/in/skeeve
> 
> PO Box 7726, Baulkham Hills, NSW 1755 Australia
> 
> The Experts Who The Experts Call
> Juniper - Cisco – IBM
> 
> 
> 
> On Sun, May 20, 2012 at 10:03 AM, scott owens wrote:
> 
>> How about Nexus 5010s.
>> 
>> I think they bundle them for less than 2 x 3750X .
>> We have both but the 3750s are used where we needed L2/L3, the 5Ks for just
>> L2 up to VSS or 7Ks.
>> 
>> 
>> you can boot them separately and they do LACP / Etherchannel just fine.
>> 
>> 
>> 
>> 
>>>  2. Stacking 3750X vs diverse 4948E (David Coulson)
>>> Message: 2
>>> Date: Fri, 18 May 2012 14:55:57 -0400
>>> From: David Coulson 
>>> To: cisco-nsp@puck.nether.net
>>> Subject: [c-nsp] Stacking 3750X vs diverse 4948E
>>> Message-ID: <4fb69b3d.3060...@davidcoulson.net>
>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>> 
>>> In a datacenter environment, we typically deploy 4948 top-of-rack
>>> switches with L2 uplinks to our 6500 core - Systems get connections into
>>> two different switches and rely on OS NIC bonding (mostly Linux) to
>>> support switch failures. Switches running STP and in the last four years
>>> we've had no issues with this design (including failures of systems
>>> connected to diverse switches).
>>> 
>>> A new proposed configuration utilizes stacked 3750X switches, where
>>> servers would be connected to multiple switches within the same stack. I
>>> have next to no experience in the low-end switches that do stacking, but
>>> from a general risk management perspective, it seems like a many eggs
>>> and single basket configuration.
>>> 
>>> Does anyone have any solid experience with 3750X switches, or stacking
>>> in a datacenter in general? I've seen plenty of stacks for
>>> closets/end-users, but I don't see many in a top-of-rack config. Is
>>> Cisco stacking typically 'reliable', in that when a switch fails it will
>>> leave the remainder of the stack functional? What about a software
>>> issue? Does the whole stack crap out and reload, or does the master just
>>> fail and a new one get elected?
>>> 
>>> I realize it's a pretty broad question, but it boils down to - Is a
>>> stacked switch config significantly less reliable/resilient/available
>>> than two TOR switches?
>>> 
>>> David
>>> 
>>> 
>> ___
>> 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] Stacking 3750X vs diverse 4948E

[Alexander Lim]

Thanks for the correction. 

Regards,
Alexander Lim

On May 19, 2012, at 6:41 PM, Daniel Husand  wrote:

> On 19/5/12 10:11 , Alexander Lim wrote:
>> When doing IOS upgrade, you need to reboot the whole switches in the stack. 
> 
> No, in 12.2(58) 3750E and X got support for RSU (rolling stack upgrade).
> 
> -- 
> Daniel

___
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] Stacking 3750X vs diverse 4948E

[Alexander Lim]

Wouwscary. 
Any clue if Nexus is better than VSS?

Regards,
Alexander Lim

On May 19, 2012, at 8:10 PM, Saku Ytti  wrote:

> On (2012-05-19 07:47 -0400), Lee wrote:
> 
>> How about VSS?  We're considering it mainly because it would eliminate STP
> 
> There are already horror stories in c-nsp, where software defect has taken
> whole VSS cluster down. STP is very unlikely to do that, as the code is lot
> simpler and lot more mature.
> 
> 
> To me it is clear that main things that cause outages are
> 
> 1. Operator
> 2. Software defect
> 3. Hardware defect
> 
> And there are huge gap between probability of each, i.e. operator is much
> more likely to break the network than software defect, and so forth.
> 
> Yet typically even high budget, high clue, critical importance networks are
> designed with only working around outages caused by 3. Often these efforts
> actually increase probability of 1 and 2. Essentially often the 'well
> design' network has lower MTBF due to the added software complexity.
> 
> Key example here is stateful firewall clusters, which I consistently see
> failing more often than single firewalls.
> When possible, I would separate elements with routing and accept that users
> will see sessions breaking when there is network fault.
> 
> If you keep eye open in press, these examples are on the news all the time,
> where CIO explains that the setup was fully redundant yadayada, it should
> have never failed.
> 
> Latest example I can think of was large outsourcing/integrator losing their
> whole 'redundant' storage setup, causing 5 day outage. Or bit longer ago,
> public sector health care had to resort to dead wood as LAN was down for
> 1.5weeks.
> Both were designed not to fail and neither was designed to workaround (or
> even rapid recover from) software defects.
> 
> -- 
>  ++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/
___
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] Stacking 3750X vs diverse 4948E

[Alexander Lim]

When doing IOS upgrade, you need to reboot the whole switches in the stack. 

Regards,
Alexander Halim

On May 19, 2012, at 5:00 AM, Keegan Holley  wrote:

> The 3750X is relatively new so I've only seen a few of them.  Stackwise in
> general is pretty solid.  I've never seen a whole stack fail.  If a member
> fails the stack just keeps going, if the master tails a new master is
> elected.  One thing to watch out for is the fact that the 3750X isn't
> intended to be a high performance DC switch.  I have seen issues with queue
> drops because of small packet buffers on the non-X version which leads to
> trouble if you do alot of 1G at line rate.  I haven't checked the X series,
> but I'm told it's not recommended for high performance environments either.
> 
> 
> 2012/5/18 David Coulson 
> 
>> In a datacenter environment, we typically deploy 4948 top-of-rack switches
>> with L2 uplinks to our 6500 core - Systems get connections into two
>> different switches and rely on OS NIC bonding (mostly Linux) to support
>> switch failures. Switches running STP and in the last four years we've had
>> no issues with this design (including failures of systems connected to
>> diverse switches).
>> 
>> A new proposed configuration utilizes stacked 3750X switches, where
>> servers would be connected to multiple switches within the same stack. I
>> have next to no experience in the low-end switches that do stacking, but
>> from a general risk management perspective, it seems like a many eggs and
>> single basket configuration.
>> 
>> Does anyone have any solid experience with 3750X switches, or stacking in
>> a datacenter in general? I've seen plenty of stacks for closets/end-users,
>> but I don't see many in a top-of-rack config. Is Cisco stacking typically
>> 'reliable', in that when a switch fails it will leave the remainder of the
>> stack functional? What about a software issue? Does the whole stack crap
>> out and reload, or does the master just fail and a new one get elected?
>> 
>> I realize it's a pretty broad question, but it boils down to - Is a
>> stacked switch config significantly less reliable/resilient/available than
>> two TOR switches?
>> 
>> David
>> 
>> __**_
>> 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] 2960s output drops

[Alexander Lim]

If it is cat 3560x/3750x, do we need to tune the buffer as well?

Regards,
Alexander Halim

On Apr 5, 2012, at 11:08 PM,  wrote:

> I don't know about this specifically, but if it's true I know I had to 
> manually tune the buffers on some 3560's just to make them bearable. I'm in 
> the process of migrating away from them onto a 6500 with WS-X6748-GE-TX's 
> instead. For what it's worth, this was how I tuned the 3560's to drastically 
> reduce (but nowhere near eliminate) the output drops due to the tiny buffers:
> 
> mls qos srr-queue output cos-map queue 2 threshold 3 0 1 2 3 4 5 6 7
> mls qos srr-queue output dscp-map queue 2 threshold 3 0 1 2 3 4 5 6 7
> mls qos srr-queue output dscp-map queue 2 threshold 3 8 9 10 11 12 13 14 15
> mls qos srr-queue output dscp-map queue 2 threshold 3 16 17 18 19 20 21 22 23
> mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
> mls qos srr-queue output dscp-map queue 2 threshold 3 32 33 34 35 36 37 38 39
> mls qos srr-queue output dscp-map queue 2 threshold 3 40 41 42 43 44 45 46 47
> mls qos srr-queue output dscp-map queue 2 threshold 3 48 49 50 51 52 53 54 55
> mls qos srr-queue output dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63
> mls qos queue-set output 1 threshold 2 400 400 100 400
> mls qos queue-set output 1 buffers 0 100 0 0
> mls qos
> 
> Props go to some blog I found this on. Hope it helps someone who might be 
> struggling with output drops on this type of platform.
> 
> -Vinny
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net 
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nikolay Shopik
> Sent: Thursday, April 05, 2012 3:48 AM
> To: Tom Sands
> Cc: Piotr Wojciechowski; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] 2960s output drops
> 
> I hear that 2960S and 3560X have almost similar buffers, do you know
> something about this?
> 
> On 04/04/12 23:11, Tom Sands wrote:
>> Beware that the 2960S incurred a drastic reduction in packet buffers 
>> compared to prior the initial 2960 product line (cut the port buffers in 
>> half).
>> 
>> 
>> From: cisco-nsp-boun...@puck.nether.net [cisco-nsp-boun...@puck.nether.net] 
>> on behalf of Nikolay Shopik [sho...@inblock.ru]
>> Sent: Wednesday, April 04, 2012 1:54 PM
>> To: Piotr Wojciechowski
>> Cc: cisco-nsp@puck.nether.net
>> Subject: Re: [c-nsp] 2960s output drops
>> 
>> Hardware is Gigabit Ethernet, address is 2c3f.386c.850c (bia 2c3f.386c.850c)
>>  Description: trestcom
>>  MTU 1500 bytes, BW 10 Kbit/sec, DLY 100 usec,
>> reliability 255/255, txload 1/255, rxload 1/255
>>  Encapsulation ARPA, loopback not set
>>  Keepalive set (10 sec)
>>  Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
>>  input flow-control is off, output flow-control is unsupported
>>  ARP type: ARPA, ARP Timeout 04:00:00
>>  Last input 00:00:01, output never, output hang never
>>  Last clearing of "show interface" counters 02:41:55
>>  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 2197
>>  Queueing strategy: fifo
>>  Output queue: 0/40 (size/max)
>>  5 minute input rate 222000 bits/sec, 139 packets/sec
>>  5 minute output rate 779000 bits/sec, 159 packets/sec
>> 1001165 packets input, 123531512 bytes, 0 no buffer
>> Received 30810 broadcasts (16248 multicasts)
>> 0 runts, 0 giants, 0 throttles
>> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
>> 0 watchdog, 16248 multicast, 0 pause input
>> 0 input packets with dribble condition detected
>> 1428427 packets output, 830613125 bytes, 0 underruns
>> 0 output errors, 0 collisions, 0 interface resets
>> 0 unknown protocol drops
>> 0 babbles, 0 late collision, 0 deferred
>> 0 lost carrier, 0 no carrier, 0 pause output
>> 0 output buffer failures, 0 output buffers swapped out
>> 
>> 
>> On 04.04.2012 21:58, Piotr Wojciechowski wrote:
>>> On 4/4/12 18:35 , Nikolay Shopik wrote:
 Hi,
 
 So we just replaced some aging c3524XL with 2960S and suddenly start
 seeing output drops on one of port facing client, while 3524 never had
 output drops to this client.
 
 Traffic levels pretty much low like 1-2mbit with 200-300pps levels. I
 believe this is because uplink now 1Gbit, but previously it was just
 100mbit and client port also 100mbit.
 
 But just wanna confirm with you guys should I ignore these drops or do
 something about.
>>> 
>>> What kind of drops are those? Can you provide us show interface output?
>>> 
>>> Regards,
>>> 
>>> 
>> ___
>> 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/
> 
>