[c-nsp] Cisco Security Advisory: Cisco Ironport Appliances Sophos Anti-virus Vulnerabilities

[Cisco Systems Product Security Incident Response Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cisco Ironport Appliances Sophos Anti-virus Vulnerabilities

Advisory ID: cisco-sa-20121108-sophos

Revision 1.0

For Public Release 2012 November 9 03:00  UTC (GMT)
- --

Summary
===

Cisco IronPort Email Security Appliances (ESA) and Cisco IronPort Web
Security Appliances (WSA) include versions of Sophos Anti-Virus that
contain multiple vulnerabilities that could allow an unauthenticated,
remote attacker to gain control of the system, escalate privileges, or
cause a denial-of-service (DoS) condition. An attacker could exploit
these vulnerabilities by sending malformed files to an appliance that
is running Sophos Anti-Virus. The malformed files could cause the
Sophos antivirus engine to behave unexpectedly.

As updates that address these vulnerabilities become available from
Sophos, Cisco is working to qualify and automatically provision them
through the Cisco Ironport ESA and WSA platforms.

A workaround that mitigates these vulnerabilities is available. This
advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20121108-sophos
 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org

iF4EAREIAAYFAlCcc5kACgkQUddfH3/BbToP4gD9EAi0HThOKyN0FiypwUcOmL8Y
b99aEPPaiqLIhNwifncA/2ijY0H+wz0TPPBbTywNoXjlgor+1AZqzzIXEOEndiMf
=6YeL
-END 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/

Re: [c-nsp] how ACLs affect the processing of a Cisco 7200 NPE-G2

[Dobbins, Roland]

On Nov 9, 2012, at 9:08 AM, Andrew Miehs wrote:

> You said your box was at 60% CPU at peak.

Where did he say this?  I didn't see any reference to this in his previous 
message . . .

---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton


___
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] how ACLs affect the processing of a Cisco 7200 NPE-G2

[Andrew Miehs]

On Fri, Nov 9, 2012 at 10:34 AM, Ali Sumsam wrote:

> Hi All,
> My question is how ACLs affect the processing of a Cisco 7200 NPE-G2.
>
> 1. Does it matter if I have a long list of ACL statements, or it is as
> CPU-consuming as 1 statement?
> 2. Is CPU processing is on a per-interface basis. For example, if I have
> one interface with ACL and another without ACL. Is it going to be the same
> in terms of CPU utilization?
>

Ali,

You said your box was at 60% CPU at peak. Although not great - I have seen
worse.
Have you even LOOKED at your process table to work out which process it is?
Are you seeing packet drops on interfaces? You are obviously using ACLs.
Why? Can't you just remove them?
Do you have other interfaces in the box other than the Gig ports on the
"supervisor"?
Why do you think you have problems - because it doesn't sound as if CPU is
your only issue.
___
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] how ACLs affect the processing of a Cisco 7200 NPE-G2

[Dobbins, Roland]

On Nov 9, 2012, at 6:34 AM, Ali Sumsam wrote:

> 1. Does it matter if I have a long list of ACL statements,

Yes.

> 2. Is CPU processing is on a per-interface basis.

No.

It's a 2mpps software-based box.  There's one processor.


---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton


___
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] how ACLs affect the processing of a Cisco 7200 NPE-G2

[Ali Sumsam]

Hi All,
My question is how ACLs affect the processing of a Cisco 7200 NPE-G2.

1. Does it matter if I have a long list of ACL statements, or it is as
CPU-consuming as 1 statement?
2. Is CPU processing is on a per-interface basis. For example, if I have
one interface with ACL and another without ACL. Is it going to be the same
in terms of CPU utilization?


Regards,


*Ali Sumsam CCIE*
*Network Engineer - Level 3*
eintellego Pty Ltd
a...@eintellego.net ; www.eintellego.net

Phone: 1300 753 383 ; Fax: (+612) 8572 9954

Cell +61 (0)410 603 531

facebook.com/eintellego
PO Box 7726, Baulkham Hills, NSW 1755 Australia

The Experts Who The Experts Call
Juniper - Cisco – Brocade - IBM
___
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] Cisco VXR GW

[M K]

Hi allCan a Cisco router VXR 7206 NPE-400 handle 2-STM1s traffic and a default 
route from an uplink provider?
Thanks
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] NAT NVI traffic usage through SNMP?

[Gauthier DOUCHET]

Hello all,

I would like to be able to retrieve traffic usage of a NVI interface
through SNMP, does someone know if it's possible?

My config is quite simple, I'm using vrf (without mpls) and NVI for
vrf-to-internet.
I can determine the traffic usage for my links in vrf (through
subinterfaces) but at this moment, I don't know how are consuming these
links on Internet through NVI.

Thank you for your answers,

Regards,
Gauthier
___
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 ASA 5505 VPN setup

[Ryan West]

So you have a VPN tunnel connecting them and you want all traffic to go through 
the tunnel to get to the Internet?   I'm not following the part about removing 
the second link though, won't you still need that for the VPN?

Sent from handheld. 

On Nov 8, 2012, at 4:32 PM, "daniel Bahamombe"  wrote:

> Hello guys 
>  
> I have two sites remote from one another but all connected to the internet by 
> two seperate ISP s using the Cisco ASA 5505 
>  
> I would want to set up a VPN tunnels bettwen the two sites and have internet 
> access from a single site as compared of getting from two links all supplying 
> internet  from seperate providers 
> I do have static IPs on both ASAs facing the public internet 
> Can anyone assist with the configuration  if its possible to set up this 
> without ISP intervention 
>  
>  
> Regards
>  
> Dan
> ___
> 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] Cisco ASA 5505 VPN setup

[daniel Bahamombe]

Hello guys 
 
I have two sites remote from one another but all connected to the internet by 
two seperate ISP s using the Cisco ASA 5505 
 
I would want to set up a VPN tunnels bettwen the two sites and have internet 
access from a single site as compared of getting from two links all supplying 
internet  from seperate providers 
I do have static IPs on both ASAs facing the public internet 
Can anyone assist with the configuration  if its possible to set up this 
without ISP intervention 
 
 
Regards
 
Dan
___
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] 7200VXR G2 performance

[David Farrell]

On Thu, Nov 8, 2012 at 8:32 PM, Nick Hilliard  wrote:

> On 08/11/2012 20:17, David Farrell wrote:
> > Only today I was taking Nick's approach to eeking out 2 x 7204s w/ G2s
> for
> > a few more weeks. I removed them from the DFZ and tore down around 120
> > direct peering BGP sessions. We now send them 8 prefixes each, including
> > default. TBH, this has had a negligible impact so I await the arrival of
> > ASR1ks to replace these. That's said, there are some intense ACLs on the
> > high traffic interfaces which could be rationalised somewhat. If there is
> > time I might have a bash at this.
>
> I should have said that the list was in order of priority.  If you can
> remove customers and traffic, you can bring down the load without reducing
> functionality.  Everything else involves a functionality / smartness
> compromise.
>
> But yeah, an npe-g2 has a limited amount of steam.  Once you've run out,
> that's kinda it.
>
> Nick
>

Absolutely, I was more intent on reporting my mileage as opposed to
anything else. Re-jigging the BGP was the only real option open to me. Our
main issues are the circa 4000 PPP session these each terminate, traffic
volume and the crazy ACLs. I'm just hoping the removal of a lot of the BGP
overhead means they don't completely melt every time a BGP update comes
in...

David.


> >
> > On Thu, Nov 8, 2012 at 10:08 AM, Nick Hilliard  > > wrote:
> >
> > On 08/11/2012 06:13, Ali Sumsam wrote:
> > > Any suggestion how can we lower the load or increase the power of
> the
> > > router. We need a temporary solution for a couple of weeks.
> > >
> > > Besides, I think removing ACLs and limiting the traffic coming from
> > > Aggregation(3560G) can help. Comments plz
> >
> > Remove:
> >
> > - customers
> > - traffic
> > - ACLs
> > - uRPF
> > - Netflow
> > - policy routing
> > - full routing
> > - more customers
> >
> > 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/
> >
> >
>
>
___
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] 7200VXR G2 performance

[Nick Hilliard]

On 08/11/2012 20:17, David Farrell wrote:
> Only today I was taking Nick's approach to eeking out 2 x 7204s w/ G2s for
> a few more weeks. I removed them from the DFZ and tore down around 120
> direct peering BGP sessions. We now send them 8 prefixes each, including
> default. TBH, this has had a negligible impact so I await the arrival of
> ASR1ks to replace these. That's said, there are some intense ACLs on the
> high traffic interfaces which could be rationalised somewhat. If there is
> time I might have a bash at this.

I should have said that the list was in order of priority.  If you can
remove customers and traffic, you can bring down the load without reducing
functionality.  Everything else involves a functionality / smartness
compromise.

But yeah, an npe-g2 has a limited amount of steam.  Once you've run out,
that's kinda it.

Nick

> 
> On Thu, Nov 8, 2012 at 10:08 AM, Nick Hilliard  > wrote:
> 
> On 08/11/2012 06:13, Ali Sumsam wrote:
> > Any suggestion how can we lower the load or increase the power of the
> > router. We need a temporary solution for a couple of weeks.
> >
> > Besides, I think removing ACLs and limiting the traffic coming from
> > Aggregation(3560G) can help. Comments plz
> 
> Remove:
> 
> - customers
> - traffic
> - ACLs
> - uRPF
> - Netflow
> - policy routing
> - full routing
> - more customers
> 
> 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/
> 
> 

___
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] 7200VXR G2 performance

[David Farrell]

Only today I was taking Nick's approach to eeking out 2 x 7204s w/ G2s for
a few more weeks. I removed them from the DFZ and tore down around 120
direct peering BGP sessions. We now send them 8 prefixes each, including
default. TBH, this has had a negligible impact so I await the arrival of
ASR1ks to replace these. That's said, there are some intense ACLs on the
high traffic interfaces which could be rationalised somewhat. If there is
time I might have a bash at this.


On Thu, Nov 8, 2012 at 10:08 AM, Nick Hilliard  wrote:

> On 08/11/2012 06:13, Ali Sumsam wrote:
> > Any suggestion how can we lower the load or increase the power of the
> > router. We need a temporary solution for a couple of weeks.
> >
> > Besides, I think removing ACLs and limiting the traffic coming from
> > Aggregation(3560G) can help. Comments plz
>
> Remove:
>
> - customers
> - traffic
> - ACLs
> - uRPF
> - Netflow
> - policy routing
> - full routing
> - more customers
>
> 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/
>
___
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

[Tim Stevenson]

At 09:36 AM 11/8/2012, Antonio Soares mused:

Thanks Tim, I will follow that procedure, it's the one that makes perfect
sense.

The documentation should be more clear about this kind of situations, don't
you think ?

There are important things that are omitted between steps 10 and 11:



You mean specific to also upgrading the DRAM? 
This particular procedure is not intended to 
cover also upgrading DRAM at the same time, 
that's not really something we assume you're doing every time you upgrade.


BTW, Sukumar does make a good point about the 
install script - it will potentially make some 
changes to the config based on updated features, 
CoPP being a prominent example.


An alternative in your case would be to just 
power off, upgrade DRAM, reboot, and then install 
all. Clearly that involves 2 reboots with a single sup.


Tim



http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/upgrade/gui
de/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Guide__Rel
ease_5.x_chapter_00.html#task_304731



Regards,

Antonio Soares, CCIE #18473 (R&S/SP)
amsoa...@netcabo.pt
http://www.ccie18473.net



-Original Message-
From: Tim Stevenson [mailto:tstev...@cisco.com]
Sent: quinta-feira, 8 de Novembro de 2012 15:51
To: Antonio Soares; 'Dirk Woellhaf'
Cc: 'cisco-nsp'; 'Charles Spurgeon'
Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade

At 07:18 AM 11/8/2012, Antonio Soares mused:
>I just have one SUP... You are talking about dual supervisors setup, right
?


Ah. In that case, clearly, the box is going to go offline when you upgrade.
You might want to consider buying another sup.

IMO, there is no huge benefit in using the install all script in a single
sup system - in the end, all it will do for you is a little sanity checking
and maybe save you from fat fingering a bootstring.

In your situation, I would copy over the new images you want; manually
change the bootstrings & save to startup; power off the box, yank the sup &
add the DRAM; and then power it all back on.

Tim



>Regards,
>
>Antonio Soares, CCIE #18473 (R&S/SP)
>amsoa...@netcabo.pt
>http://www.ccie18473.net
>
>
>
>-Original Message-
>From: Dirk Woellhaf [mailto:dirk.woell...@gmail.com]
>Sent: quinta-feira, 8 de Novembro de 2012 14:10
>To: Antonio Soares
>Cc: Charles Spurgeon; cisco-nsp
>Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade
>
>Hi Antonio,
>
>You should be able to do the memory-upgrade without rebooting the box.
>I've never done it on my I own but I know a few which did without any
>problem. I believe they first upgraded the memory and then did the update!
>
>Dirk
>
>Sent from my iPhone
>
>On 08.11.2012, at 13:42, Antonio Soares  wrote:
>
> > Thanks, I don't know if you noticed but somewhere in the thread the
> > bug was mentioned and it is resolved in 5.1.5 and later.
> >
> > Bug CSCtn61286 - Boot variables are not set up correctly on Sup-2
> > after ISSU
> >
> > So in my case, it should not give me problems (5.2.3a to 5.2.7).
> >
> > But since I also need to upgrade the SUP1 RAM from 4G to 8G, I have
> > no other option than doing the traditional upgrade. It's the only
> > way to just send the box down 1 time:
> >
> > - update the boot variables
> > - power off and upgrade the RAM
> > - power on
> >
> > The install all script has another limitation: it won't let us to
> > reboot when we chose to do it. This is what happened to me last time:
> >
> > +
> > Switch will be reloaded for disruptive upgrade.
> > Do you want to continue with the installation (y/n)?  y
> >
> > Install is in progress, please wait.
> >
> > (..)
> >
> > A few minutes later:
> >
> > Finishing the upgrade, switch will reboot in 10 seconds.
> > +
> >
> > I don't see how to upgrade the RAM and upgrade the NX-OS with the
> > install script in just one shot...
> >
> >
> > Regards,
> >
> > Antonio Soares, CCIE #18473 (R&S/SP) amsoa...@netcabo.pt
> > http://www.ccie18473.net
> >
> >
> > -Original Message-
> > From: Charles Spurgeon [mailto:c.spurg...@austin.utexas.edu]
> > Sent: quinta-feira, 8 de Novembro de 2012 00:50
> > To: Antonio Soares
> > Cc: 'Tóth András'; 'cisco-nsp'
> > Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade
> >
> > 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
> >>

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

[Antonio Soares]

Thanks Tim, I will follow that procedure, it's the one that makes perfect
sense.

The documentation should be more clear about this kind of situations, don't
you think ?

There are important things that are omitted between steps 10 and 11:

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/upgrade/gui
de/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Guide__Rel
ease_5.x_chapter_00.html#task_304731



Regards,

Antonio Soares, CCIE #18473 (R&S/SP)
amsoa...@netcabo.pt
http://www.ccie18473.net



-Original Message-
From: Tim Stevenson [mailto:tstev...@cisco.com] 
Sent: quinta-feira, 8 de Novembro de 2012 15:51
To: Antonio Soares; 'Dirk Woellhaf'
Cc: 'cisco-nsp'; 'Charles Spurgeon'
Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade

At 07:18 AM 11/8/2012, Antonio Soares mused:
>I just have one SUP... You are talking about dual supervisors setup, right
?


Ah. In that case, clearly, the box is going to go offline when you upgrade.
You might want to consider buying another sup.

IMO, there is no huge benefit in using the install all script in a single
sup system - in the end, all it will do for you is a little sanity checking
and maybe save you from fat fingering a bootstring.

In your situation, I would copy over the new images you want; manually
change the bootstrings & save to startup; power off the box, yank the sup &
add the DRAM; and then power it all back on.

Tim



>Regards,
>
>Antonio Soares, CCIE #18473 (R&S/SP)
>amsoa...@netcabo.pt
>http://www.ccie18473.net
>
>
>
>-Original Message-
>From: Dirk Woellhaf [mailto:dirk.woell...@gmail.com]
>Sent: quinta-feira, 8 de Novembro de 2012 14:10
>To: Antonio Soares
>Cc: Charles Spurgeon; cisco-nsp
>Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade
>
>Hi Antonio,
>
>You should be able to do the memory-upgrade without rebooting the box.
>I've never done it on my I own but I know a few which did without any 
>problem. I believe they first upgraded the memory and then did the update!
>
>Dirk
>
>Sent from my iPhone
>
>On 08.11.2012, at 13:42, Antonio Soares  wrote:
>
> > Thanks, I don't know if you noticed but somewhere in the thread the 
> > bug was mentioned and it is resolved in 5.1.5 and later.
> >
> > Bug CSCtn61286 - Boot variables are not set up correctly on Sup-2 
> > after ISSU
> >
> > So in my case, it should not give me problems (5.2.3a to 5.2.7).
> >
> > But since I also need to upgrade the SUP1 RAM from 4G to 8G, I have 
> > no other option than doing the traditional upgrade. It's the only 
> > way to just send the box down 1 time:
> >
> > - update the boot variables
> > - power off and upgrade the RAM
> > - power on
> >
> > The install all script has another limitation: it won't let us to 
> > reboot when we chose to do it. This is what happened to me last time:
> >
> > +
> > Switch will be reloaded for disruptive upgrade.
> > Do you want to continue with the installation (y/n)?  y
> >
> > Install is in progress, please wait.
> >
> > (..)
> >
> > A few minutes later:
> >
> > Finishing the upgrade, switch will reboot in 10 seconds.
> > +
> >
> > I don't see how to upgrade the RAM and upgrade the NX-OS with the 
> > install script in just one shot...
> >
> >
> > Regards,
> >
> > Antonio Soares, CCIE #18473 (R&S/SP) amsoa...@netcabo.pt 
> > http://www.ccie18473.net
> >
> >
> > -Original Message-
> > From: Charles Spurgeon [mailto:c.spurg...@austin.utexas.edu]
> > Sent: quinta-feira, 8 de Novembro de 2012 00:50
> > To: Antonio Soares
> > Cc: 'Tóth András'; 'cisco-nsp'
> > Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade
> >
> > 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
> >>

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

[Sukumar Subburayan (sukumars)]

Any new CoPP best Practice configs update available in the new code is applied 
only when using install script.

sukumar

Thumb typed on my Smartphone. Excuse Typos.

On Nov 8, 2012, at 7:54 AM, "Tim Stevenson (tstevens)"  
wrote:

> At 07:18 AM 11/8/2012, Antonio Soares mused:
>> I just have one SUP... You are talking about dual supervisors setup, right ?
> 
> 
> Ah. In that case, clearly, the box is going to go offline when you upgrade. 
> You might want to consider buying another sup.
> 
> IMO, there is no huge benefit in using the install all script in a single sup 
> system - in the end, all it will do for you is a little sanity checking and 
> maybe save you from fat fingering a bootstring.
> 
> In your situation, I would copy over the new images you want; manually change 
> the bootstrings & save to startup; power off the box, yank the sup & add the 
> DRAM; and then power it all back on.
> 
> Tim
> 
> 
> 
>> Regards,
>> 
>> Antonio Soares, CCIE #18473 (R&S/SP)
>> amsoa...@netcabo.pt
>> http://www.ccie18473.net
>> 
>> 
>> 
>> -Original Message-
>> From: Dirk Woellhaf [mailto:dirk.woell...@gmail.com]
>> Sent: quinta-feira, 8 de Novembro de 2012 14:10
>> To: Antonio Soares
>> Cc: Charles Spurgeon; cisco-nsp
>> Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade
>> 
>> Hi Antonio,
>> 
>> You should be able to do the memory-upgrade without rebooting the box.
>> I've never done it on my I own but I know a few which did without any
>> problem. I believe they first upgraded the memory and then did the update!
>> 
>> Dirk
>> 
>> Sent from my iPhone
>> 
>> On 08.11.2012, at 13:42, Antonio Soares  wrote:
>> 
>> > Thanks, I don't know if you noticed but somewhere in the thread the
>> > bug was mentioned and it is resolved in 5.1.5 and later.
>> >
>> > Bug CSCtn61286 - Boot variables are not set up correctly on Sup-2
>> > after ISSU
>> >
>> > So in my case, it should not give me problems (5.2.3a to 5.2.7).
>> >
>> > But since I also need to upgrade the SUP1 RAM from 4G to 8G, I have no
>> > other option than doing the traditional upgrade. It's the only way to
>> > just send the box down 1 time:
>> >
>> > - update the boot variables
>> > - power off and upgrade the RAM
>> > - power on
>> >
>> > The install all script has another limitation: it won't let us to
>> > reboot when we chose to do it. This is what happened to me last time:
>> >
>> > +
>> > Switch will be reloaded for disruptive upgrade.
>> > Do you want to continue with the installation (y/n)?  y
>> >
>> > Install is in progress, please wait.
>> >
>> > (..)
>> >
>> > A few minutes later:
>> >
>> > Finishing the upgrade, switch will reboot in 10 seconds.
>> > +
>> >
>> > I don't see how to upgrade the RAM and upgrade the NX-OS with the
>> > install script in just one shot...
>> >
>> >
>> > Regards,
>> >
>> > Antonio Soares, CCIE #18473 (R&S/SP)
>> > amsoa...@netcabo.pt
>> > http://www.ccie18473.net
>> >
>> >
>> > -Original Message-
>> > From: Charles Spurgeon [mailto:c.spurg...@austin.utexas.edu]
>> > Sent: quinta-feira, 8 de Novembro de 2012 00:50
>> > To: Antonio Soares
>> > Cc: 'Tóth András'; 'cisco-nsp'
>> > Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade
>> >
>> > 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?met
>> >> h
>> >> od=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.
>> >>
>> >> Upgradi

Re: [c-nsp] 7200VXR G2 performance

[Chuck Church]

What features are enabled?  NBAR, NetFlow, NAT, QoS, ACLs with logging (or
even without), etc will all affect it.

Chuck

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ali Sumsam
Sent: Thursday, November 08, 2012 1:14 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] 7200VXR G2 performance

Hi All,
One of our customer's border router which is G2 is having a lot of load on
it. We observe packet loss when throughput reaches to maximum.

Any suggestion how can we lower the load or increase the power of the
router. We need a temporary solution for a couple of weeks.

Besides, I think removing ACLs and limiting the traffic coming from
Aggregation(3560G) can help. Comments plz


Regards,



*Ali Sumsam CCIE*
*Network Engineer - Level 3*
eintellego Pty Ltd
a...@eintellego.net ; www.eintellego.net

Phone: 1300 753 383 ; Fax: (+612) 8572 9954

Cell +61 (0)410 603 531

facebook.com/eintellego
PO Box 7726, Baulkham Hills, NSW 1755 Australia

The Experts Who The Experts Call
Juniper - Cisco - Brocade - IBM
___
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

[Tim Stevenson]

At 07:18 AM 11/8/2012, Antonio Soares mused:

I just have one SUP... You are talking about dual supervisors setup, right ?



Ah. In that case, clearly, the box is going to go 
offline when you upgrade. You might want to consider buying another sup.


IMO, there is no huge benefit in using the 
install all script in a single sup system - in 
the end, all it will do for you is a little 
sanity checking and maybe save you from fat fingering a bootstring.


In your situation, I would copy over the new 
images you want; manually change the bootstrings 
& save to startup; power off the box, yank the 
sup & add the DRAM; and then power it all back on.


Tim




Regards,

Antonio Soares, CCIE #18473 (R&S/SP)
amsoa...@netcabo.pt
http://www.ccie18473.net



-Original Message-
From: Dirk Woellhaf [mailto:dirk.woell...@gmail.com]
Sent: quinta-feira, 8 de Novembro de 2012 14:10
To: Antonio Soares
Cc: Charles Spurgeon; cisco-nsp
Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade

Hi Antonio,

You should be able to do the memory-upgrade without rebooting the box.
I've never done it on my I own but I know a few which did without any
problem. I believe they first upgraded the memory and then did the update!

Dirk

Sent from my iPhone

On 08.11.2012, at 13:42, Antonio Soares  wrote:

> Thanks, I don't know if you noticed but somewhere in the thread the
> bug was mentioned and it is resolved in 5.1.5 and later.
>
> Bug CSCtn61286 - Boot variables are not set up correctly on Sup-2
> after ISSU
>
> So in my case, it should not give me problems (5.2.3a to 5.2.7).
>
> But since I also need to upgrade the SUP1 RAM from 4G to 8G, I have no
> other option than doing the traditional upgrade. It's the only way to
> just send the box down 1 time:
>
> - update the boot variables
> - power off and upgrade the RAM
> - power on
>
> The install all script has another limitation: it won't let us to
> reboot when we chose to do it. This is what happened to me last time:
>
> +
> Switch will be reloaded for disruptive upgrade.
> Do you want to continue with the installation (y/n)?  y
>
> Install is in progress, please wait.
>
> (..)
>
> A few minutes later:
>
> Finishing the upgrade, switch will reboot in 10 seconds.
> +
>
> I don't see how to upgrade the RAM and upgrade the NX-OS with the
> install script in just one shot...
>
>
> Regards,
>
> Antonio Soares, CCIE #18473 (R&S/SP)
> amsoa...@netcabo.pt
> http://www.ccie18473.net
>
>
> -Original Message-
> From: Charles Spurgeon [mailto:c.spurg...@austin.utexas.edu]
> Sent: quinta-feira, 8 de Novembro de 2012 00:50
> To: Antonio Soares
> Cc: 'Tóth András'; 'cisco-nsp'
> Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade
>
> 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?met
>> h
>> od=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/upg
>>> ra
>>> de/gui
>

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

[Tim Stevenson]

At 04:37 AM 11/8/2012, Antonio Soares mused:

Thanks, I don't know if you noticed but somewhere in the thread the bug was
mentioned and it is resolved in 5.1.5 and later.

Bug CSCtn61286 - Boot variables are not set up correctly on Sup-2 after ISSU

So in my case, it should not give me problems (5.2.3a to 5.2.7).

But since I also need to upgrade the SUP1 RAM from 4G to 8G, I have no other
option than doing the traditional upgrade. It's the only way to just send
the box down 1 time:



You should not need to take the box down to do a 
DRAM upgrade if you have 2 sups. Provided you're 
on 5.1 or later you don't need to upgrade the 
software/do an ISSU either. You will perform a 
stateful switchover from the active to the 
standby sup at one point in the process in order 
to upgrade the memory on the second sup.


The procedure is described in the user docs:
http://www.cisco.com/en/US/docs/switches/datacenter/hw/nexus7000/installation/guide/n7k_replacing.html#wp1272213

This procedure is completely unrelated to 
upgrading the software (provided you're already 
on/past the minimum release to support 8GB which is 5.1(1)).


I would point out that at Step 21, you need to 
make sure to wait for the newly inserted 8GB sup 
come fully online and enter hot standby mode 
before attempting to switchover/yank the other sup.


Tim



- update the boot variables
- power off and upgrade the RAM
- power on

The install all script has another limitation: it won't let us to reboot
when we chose to do it. This is what happened to me last time:

+
Switch will be reloaded for disruptive upgrade.
Do you want to continue with the installation (y/n)?  y

Install is in progress, please wait.

(..)

A few minutes later:

Finishing the upgrade, switch will reboot in 10 seconds.
+

I don't see how to upgrade the RAM and upgrade the NX-OS with the install
script in just one shot...


Regards,

Antonio Soares, CCIE #18473 (R&S/SP)
amsoa...@netcabo.pt
http://www.ccie18473.net


-Original Message-
From: Charles Spurgeon [mailto:c.spurg...@austin.utexas.edu]
Sent: quinta-feira, 8 de Novembro de 2012 00:50
To: Antonio Soares
Cc: 'Tóth András'; 'cisco-nsp'
Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade

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?meth
> od=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/upg
> > ra
> > de/gui
> > de/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Gu
> > id
> > 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/upg
> > ra
> > de/gui
> > de/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Gu
> > id
> > 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 upg

[c-nsp] route leaking from global to VRF on cisco 7401

[Warwick Duncan]

Hi

I'm having a problem leaking routes from the global routing table into a
VRF on a Cisco 7401 and I'd appreciate an opinion on whether my config
or the router is at fault.  The IOS image is c7400-jk9s-mz.124-21a.bin,
which is the most recent to which I have access.

Let's say my local router is 1.1.1.1, remote router is 1.2.2.2, my ASN
is 1 and upstream provider ASN is 9.  I want to distribute
10.0.0.0/0 for the MYVPN VRF between the two routers and Internet
breakout is via the remote router, but I want to import local peering
routes (let's say ASN 5) on the local router from the global routing
table into MYVPN.  There is source based VRF selection on the downstream
facing interface.

Before configuring route leaking, the relevant parts of the (sanitised)
config look like this:


ip vrf MYVPN
 rd 1:21003
 route-target export 1:21003
 route-target import 1:21003
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface GigabitEthernet0/0
 mtu 1580
 no ip address
 duplex auto
 speed auto
 media-type gbic
 negotiation auto
!
interface GigabitEthernet0/0.2
 description Downstream Interconnect
 encapsulation dot1Q 2
 ip vrf receive MYVPN
 ip address 192.168.0.9 255.255.255.248
 no ip redirects
 no ip proxy-arp
 ip mtu 1500
 ip flow ingress
 ip flow egress
 ip ospf cost 1000
 ip policy route-map pbr-from-downstream
!
router bgp 1
 no synchronization
 bgp router-id 1.1.1.1
 bgp default local-preference 1000
 no bgp enforce-first-as
 bgp log-neighbor-changes
 neighbor REMOTE peer-group
 neighbor REMOTE remote-as 1
 neighbor REMOTE update-source Loopback0
 neighbor REMOTE next-hop-self
 neighbor REMOTE send-community both
 neighbor REMOTE soft-reconfiguration inbound
 neighbor REMOTE weight 100
 neighbor REMOTE prefix-list ANY in
 neighbor PEERING peer-group
 neighbor PEERING soft-reconfiguration inbound
 neighbor PEERING weight 50
 neighbor PEERING route-map recv-from-peers in
 neighbor PEERING maximum-prefix 1000
 neighbor 2.2.2.2 peer-group REMOTE
 neighbor 4.3.2.1 peer-group PEERING
 default-metric 10
 no auto-summary
 !
 address-family vpnv4
  neighbor REMOTE send-community extended
  neighbor 2.2.2.2 activate
 exit-address-family
 !
 address-family ipv4 vrf MYVPN
  no synchronization
  network 10.1.1.0 mask 255.255.255.0
 exit-address-family
!
ip route vrf MYVPN 10.1.1.0 255.255.255.0 192.168.0.1 global permanent
!
ip community-list standard peer-com permit 1:11050
!
route-map pbr-from-downstream permit 10
 match ip address FROM-10-1-1-0
 set vrf MYVPN
!
route-map recv-from-peers permit 10
 set community 1:11050


At this point both the entries in the BGP RIB for MYVPN are as expected,
as is the VRF's routing table itself, i.e. it sees the remote VPN prefix
10.1.1.0/24 and the default route propagated from an eBGP peer:


router1#show ip bgp vpnv4 all 
BGP table version is 14, local router ID is 1.1.1.1
[..]
   Network  Next HopMetric LocPrf Weight Path
Route Distinguisher: 1:21003 (default for vrf MYVPN)
*>i0.0.0.0  2.2.2.2  0   2000  0 9 i
*>i10.2.2.0/24  2.2.2.2 10   1000  0 i
*> 10.1.1.0/24  192.168.0.1 10 32768 i

router1#show ip route vrf MYVPN

Routing Table: MYVPN
[..]
Gateway of last resort is 2.2.2.2 to network 0.0.0.0

B   10.2.2.0/24 [200/10] via 2.2.2.2, 11:31:20
C   192.168.0.8/29 is directly connected, GigabitEthernet0/0.2
S   10.1.1.0/24 [1/0] via 192.168.0.1
B*   0.0.0.0/0 [200/0] via 2.2.2.2, 11:31:20


So far so good; now I modify the config to import the peering routes
from the global routing table into the MYVPN VRF:


ip vrf MYVPN
 rd 1:21003
 import ipv4 unicast map leak-peering
 route-target export 1:21003
 route-target import 1:21003
!
route-map leak-peering permit 10
 match community peer-com


At this point, things fall apart.  The BGP RIB is correct but in my most
recent attempt, the peering routes appeared in the VRF routing table
(FIB) but the default route disappeared.  On various other attempts
- all routes except the peering routes disappear from FIB;
- all routes except connected and static disappear from FIB;
- some VPN routes disappear from RIB.

(I hope I'm using RIB and FIB correctly...)

If I remove the 'import ipv4 ...' config item, the leaked peering routes
remain in the BGP RIB but disappear from the VRF FIB; clearing all BGP
neighbors causes no visible change.  Removing the VRF entirely leaves

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

[Antonio Soares]

I just have one SUP... You are talking about dual supervisors setup, right ?


Regards,

Antonio Soares, CCIE #18473 (R&S/SP)
amsoa...@netcabo.pt
http://www.ccie18473.net



-Original Message-
From: Dirk Woellhaf [mailto:dirk.woell...@gmail.com] 
Sent: quinta-feira, 8 de Novembro de 2012 14:10
To: Antonio Soares
Cc: Charles Spurgeon; cisco-nsp
Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade

Hi Antonio,

You should be able to do the memory-upgrade without rebooting the box.
I've never done it on my I own but I know a few which did without any
problem. I believe they first upgraded the memory and then did the update!

Dirk

Sent from my iPhone

On 08.11.2012, at 13:42, Antonio Soares  wrote:

> Thanks, I don't know if you noticed but somewhere in the thread the 
> bug was mentioned and it is resolved in 5.1.5 and later.
>
> Bug CSCtn61286 - Boot variables are not set up correctly on Sup-2 
> after ISSU
>
> So in my case, it should not give me problems (5.2.3a to 5.2.7).
>
> But since I also need to upgrade the SUP1 RAM from 4G to 8G, I have no 
> other option than doing the traditional upgrade. It's the only way to 
> just send the box down 1 time:
>
> - update the boot variables
> - power off and upgrade the RAM
> - power on
>
> The install all script has another limitation: it won't let us to 
> reboot when we chose to do it. This is what happened to me last time:
>
> +
> Switch will be reloaded for disruptive upgrade.
> Do you want to continue with the installation (y/n)?  y
>
> Install is in progress, please wait.
>
> (….)
>
> A few minutes later:
>
> Finishing the upgrade, switch will reboot in 10 seconds.
> +
>
> I don't see how to upgrade the RAM and upgrade the NX-OS with the 
> install script in just one shot...
>
>
> Regards,
>
> Antonio Soares, CCIE #18473 (R&S/SP)
> amsoa...@netcabo.pt
> http://www.ccie18473.net
>
>
> -Original Message-
> From: Charles Spurgeon [mailto:c.spurg...@austin.utexas.edu]
> Sent: quinta-feira, 8 de Novembro de 2012 00:50
> To: Antonio Soares
> Cc: 'Tóth András'; 'cisco-nsp'
> Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade
>
> 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?met
>> h
>> od=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/upg
>>> ra
>>> de/gui
>>> de/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Gu
>>> id
>>> 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/upg
>>> ra
>>> de/gui
>>> de/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Gu
>>> id
>>> 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 on

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

[Dirk Woellhaf]

Hi Antonio,

You should be able to do the memory-upgrade without rebooting the box.
I've never done it on my I own but I know a few which did without any
problem. I believe they first upgraded the memory and then did the
update!

Dirk

Sent from my iPhone

On 08.11.2012, at 13:42, Antonio Soares  wrote:

> Thanks, I don't know if you noticed but somewhere in the thread the bug was
> mentioned and it is resolved in 5.1.5 and later.
>
> Bug CSCtn61286 - Boot variables are not set up correctly on Sup-2 after ISSU
>
> So in my case, it should not give me problems (5.2.3a to 5.2.7).
>
> But since I also need to upgrade the SUP1 RAM from 4G to 8G, I have no other
> option than doing the traditional upgrade. It's the only way to just send
> the box down 1 time:
>
> - update the boot variables
> - power off and upgrade the RAM
> - power on
>
> The install all script has another limitation: it won't let us to reboot
> when we chose to do it. This is what happened to me last time:
>
> +
> Switch will be reloaded for disruptive upgrade.
> Do you want to continue with the installation (y/n)?  y
>
> Install is in progress, please wait.
>
> (….)
>
> A few minutes later:
>
> Finishing the upgrade, switch will reboot in 10 seconds.
> +
>
> I don't see how to upgrade the RAM and upgrade the NX-OS with the install
> script in just one shot...
>
>
> Regards,
>
> Antonio Soares, CCIE #18473 (R&S/SP)
> amsoa...@netcabo.pt
> http://www.ccie18473.net
>
>
> -Original Message-
> From: Charles Spurgeon [mailto:c.spurg...@austin.utexas.edu]
> Sent: quinta-feira, 8 de Novembro de 2012 00:50
> To: Antonio Soares
> Cc: 'Tóth András'; 'cisco-nsp'
> Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade
>
> 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?meth
>> od=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/upg
>>> ra
>>> de/gui
>>> de/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Gu
>>> id
>>> 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/upg
>>> ra
>>> de/gui
>>> de/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Gu
>>> id
>>> 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 

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

[Antonio Soares]

Yes it is. But you can still use the ISSU method of doing things (install all) 
with just one SUP. It doesn't make too much sense, right ?


Regards,

Antonio Soares, CCIE #18473 (R&S/SP)
amsoa...@netcabo.pt
http://www.ccie18473.net



-Original Message-
From: Alexander Lim [mailto:nsp.alexander@gmail.com] 
Sent: quinta-feira, 8 de Novembro de 2012 04:56
To: Charles Spurgeon
Cc: Antonio Soares; cisco-nsp
Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade

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?met
>> hod=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/upg
>>> ra
>>> de/gui
>>> de/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Gu
>>> id
>>> 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/upg
>>> ra
>>> de/gui
>>> de/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Gu
>>> id
>>> 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 
>>> 
>>> ___
>>> 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.net

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

[Antonio Soares]

Thanks, I don't know if you noticed but somewhere in the thread the bug was
mentioned and it is resolved in 5.1.5 and later.

Bug CSCtn61286 - Boot variables are not set up correctly on Sup-2 after ISSU

So in my case, it should not give me problems (5.2.3a to 5.2.7).

But since I also need to upgrade the SUP1 RAM from 4G to 8G, I have no other
option than doing the traditional upgrade. It's the only way to just send
the box down 1 time:

- update the boot variables
- power off and upgrade the RAM
- power on

The install all script has another limitation: it won't let us to reboot
when we chose to do it. This is what happened to me last time:

+
Switch will be reloaded for disruptive upgrade.
Do you want to continue with the installation (y/n)?  y
 
Install is in progress, please wait.
 
(….)
 
A few minutes later:
 
Finishing the upgrade, switch will reboot in 10 seconds.
+

I don't see how to upgrade the RAM and upgrade the NX-OS with the install
script in just one shot...


Regards,

Antonio Soares, CCIE #18473 (R&S/SP)
amsoa...@netcabo.pt
http://www.ccie18473.net


-Original Message-
From: Charles Spurgeon [mailto:c.spurg...@austin.utexas.edu] 
Sent: quinta-feira, 8 de Novembro de 2012 00:50
To: Antonio Soares
Cc: 'Tóth András'; 'cisco-nsp'
Subject: Re: [c-nsp] Nexus 7K NX-OS Upgrade

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?meth
> od=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/upg
> > ra
> > de/gui
> > de/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Gu
> > id
> > 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/upg
> > ra
> > de/gui
> > de/b_Cisco_Nexus_7000_Series_NX-OS_Software_Upgrade_and_Downgrade_Gu
> > id
> > 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 (

Re: [c-nsp] 7200VXR G2 performance

[Nick Hilliard]

On 08/11/2012 06:13, Ali Sumsam wrote:
> Any suggestion how can we lower the load or increase the power of the
> router. We need a temporary solution for a couple of weeks.
> 
> Besides, I think removing ACLs and limiting the traffic coming from
> Aggregation(3560G) can help. Comments plz

Remove:

- customers
- traffic
- ACLs
- uRPF
- Netflow
- policy routing
- full routing
- more customers

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] BGP NSR without SSO

[zaid]

Hi adam  

thanks for the response, but the bgp advertise-best-external can only work with 
VPNv4, VPNv6, IPv4 VRF, and IPv6 VRF address families. , and not all of the 
above is our scenario .

thanks





 From: Adam Vitkovsky 
To: 'zaid' ; cisco-nsp@puck.nether.net 
Sent: Wednesday, November 7, 2012 6:38 PM
Subject: RE: [c-nsp] BGP NSR without SSO
 
Hi Zaid,

> decrease the packet loss when link flapped without BGP sessions reset
You can use BFD with eBGP peers

Than you can use 

either:
address-family ipv4 vrf 1
  maximum-paths eibgp 8
  bgp advertise-best-external

or:
address-family ipv4 vrf 1
  bgp advertise-best-external
  bgp additional-paths install
  maximum-paths 8
  maximum-paths ibgp 8


adam
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of zaid
Sent: Wednesday, November 07, 2012 1:22 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] BGP NSR without SSO

Hi all 

How can deploy BGP NSR without SSO on 12000 XR or such mechanism to decrease
the packet loss when link flapped without BGP sessions reset ( ex: XR Router
multi homed with different ISP )

the packet loss happens on the other during the recalculation of the best
path.



thanks 

ZH
___
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/