From davidwarner1975 at yahoo.com.au  Tue Sep  1 00:45:56 2009
From: davidwarner1975 at yahoo.com.au (David Warner)
Date: Mon, 31 Aug 2009 21:45:56 -0700 (PDT)
Subject: [c-nsp] Troubleshooting High CPU
In-Reply-To: <E0369829-18B6-48F0-A304-0021E78BEF3C@gmail.com>
References: <E0369829-18B6-48F0-A304-0021E78BEF3C@gmail.com>
Message-ID: <228424.23640.qm@web111601.mail.gq1.yahoo.com>

Hi - Thanks for the feedback.

Yes - same hardware (3845), sw, config and traffic. Just deployed as active/standby for HSRP. The chief suspect is the port channel between the ESWs but would like to get the info to confirm whether its spanning tree or another culprit. 

Im unable to get any useful info out the box as when it occurs the CPU spikes and hits VTY so unable to get any commands back. Is there anyway to reserve a minimum amount of CPU to VTY so we can at least issue the commands while the problem is occuring? 

Regards, David




________________________________
From: Eninja <eninja at gmail.com>
To: David Warner <davidwarner1975 at yahoo.com.au>
Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>; Eninja <eninja at gmail.com>
Sent: Tuesday, 1 September, 2009 12:11:07 PM
Subject: Re: [c-nsp] Troubleshooting High CPU

What platform is the device? Are the primary and standby devices the same - platform, SW, config, traffic?

During the spike, is the CPU consumed at interrupt or process level?

Grab and send over sh proc cpu, sh align, sh int stat, sh log (if device is too unresponsive during failover, have onsite personnel pull out traffic-laden cables one by one until device is responsive, grab captures before reinserting cable/s).

-Eninja
PS. Disable console logging


On Aug 31, 2009, at 10:46 PM, David Warner <davidwarner1975 at yahoo.com..au> wrote:

> Hi All,
> 
> Just wondering if I can get some advice.. We have two routers in a HSRP active/standby pair. If ones reloads then the CPU on the other hits 100% and crashes. The only way we can recover this is for a field engineer to pull all the Ethernet cables out and then, when system is calm, repatch them. We access the device via VTY so struggling to actually get any commands in to troubleshoot as per the Cisco 'Troubleshooting High CPU Utilization' doc as the CPU spikes .
> 
> Any advice on best way to progress this?
> 
> Regards, David
> 
> 
> 
>     __________________________________________________________________________________



> Find local businesses and services in your area with Yahoo!7 Local.
> Get started: http://local.yahoo.com.au
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck..nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


      __________________________________________________________________________________
Find local businesses and services in your area with Yahoo!7 Local.
Get started: http://local.yahoo.com.au

From vedlabs at gmail.com  Tue Sep  1 01:41:34 2009
From: vedlabs at gmail.com (Ved Labs)
Date: Tue, 1 Sep 2009 11:11:34 +0530
Subject: [c-nsp] dampening for VPNv4
In-Reply-To: <7db92dcc0908290435s2c9b32eerc64f076eea1f17a2@mail.gmail.com>
References: <7db92dcc0908290435s2c9b32eerc64f076eea1f17a2@mail.gmail.com>
Message-ID: <7db92dcc0908312241w6951ead8x77efa9b781484414@mail.gmail.com>

Hi Team ,

 any comments on this .

Thanks,
Ved.

On Sat, Aug 29, 2009 at 5:05 PM, Ved Labs <vedlabs at gmail.com> wrote:

> I would like to know the pros and cons for enabling the dampening for VPNv4
> .
>
> I can see a lot of vpnv4 routes flapping and causing the cpu shoot .
>
> Thanks,
> Ved.
>

From chris.garzon at gmail.com  Tue Sep  1 02:47:48 2009
From: chris.garzon at gmail.com (Dracul)
Date: Tue, 1 Sep 2009 14:47:48 +0800
Subject: [c-nsp] some WCCP questions
Message-ID: <876789290908312347m14a5f8f2n647c4529d95b44de@mail.gmail.com>

Hi List,

I'm planning to setup WCCP + Squid.

If the squid server should be offline or the squid process dies, will the
users? port 80 requests automatically redirect to the ?live? internet
connection??
Because in old "forced" redirection configurations, if the squid process
dies or should the squid server be unreachable for some reason, user will
see a browser error.

>From what I understand with WCCP documentation,  if the squid dies or the
server is unreachable, the network should automatically redirect the users
to the gateway, without
any disruption of any kind to their browsing experience. Are my assumptions
correct? Thanks!

Chris

From adrian at creative.net.au  Tue Sep  1 02:52:08 2009
From: adrian at creative.net.au (Adrian Chadd)
Date: Tue, 1 Sep 2009 14:52:08 +0800
Subject: [c-nsp] some WCCP questions
In-Reply-To: <876789290908312347m14a5f8f2n647c4529d95b44de@mail.gmail.com>
References: <876789290908312347m14a5f8f2n647c4529d95b44de@mail.gmail.com>
Message-ID: <20090901065208.GB7719@skywalker.creative.net.au>

On Tue, Sep 01, 2009, Dracul wrote:
> Hi List,
> 
> I'm planning to setup WCCP + Squid.

Hi!

> If the squid server should be offline or the squid process dies, will the
> users? port 80 requests automatically redirect to the ?live? internet
> connection??

Yes!

> Because in old "forced" redirection configurations, if the squid process
> dies or should the squid server be unreachable for some reason, user will
> see a browser error.

Indeed.

> >From what I understand with WCCP documentation,  if the squid dies or the
> server is unreachable, the network should automatically redirect the users
> to the gateway, without

That takes time - the WCCPv2 router will take a while to time out the
now-unreachable server. It would be possible to hack in some code to try
sending a last "gasping breath" packet to the WCCPv2 router to say the
cache is about to disappear, but it won't save existing connections.

> any disruption of any kind to their browsing experience. Are my assumptions
> correct? Thanks!



adrian


-- 
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -

From td_miles at yahoo.com  Tue Sep  1 02:56:41 2009
From: td_miles at yahoo.com (Tony)
Date: Mon, 31 Aug 2009 23:56:41 -0700 (PDT)
Subject: [c-nsp] slow down VTY speed
Message-ID: <13508.50650.qm@web110109.mail.gq1.yahoo.com>

Hi all,

I'm wondering if there is a way to slow down the speed of VTY (telnet) sessions on a Cisco router ?

We have the situation that when RANCID grabs a config from an older 7204 with NPE-300 it causes the CPU to hit 100% for a long 4-5 seconds, which is long enough for OSPF with 1 second hello-interval to time out and declare neighbours dead.

I've read the cisco doco on troubleshooting high CPU due to exec & vexec processes:

http://www.cisco.com/en/US/products/hw/routers/ps359/products_tech_note09186a00801c2ae4.shtml

I know that the problem is the volume of data being transferred to the telnet session, all I want to do is throttle it a little bit. I wouldn't be concerned if it took twice as long for RANCID to grab the config from this device if it helped stop the timeouts. 

Any suggestions appreciated.


Thanks,
Tony.


      __________________________________________________________________________________
Find local businesses and services in your area with Yahoo!7 Local.
Get started: http://local.yahoo.com.au


From p.caci at seabone.net  Tue Sep  1 03:28:23 2009
From: p.caci at seabone.net (Pierfrancesco Caci)
Date: Tue, 01 Sep 2009 09:28:23 +0200
Subject: [c-nsp] slow down VTY speed
In-Reply-To: <13508.50650.qm@web110109.mail.gq1.yahoo.com>
	(td_miles@yahoo.com's message of "Mon, 31 Aug 2009 23:56:41 -0700
	(PDT)")
References: <13508.50650.qm@web110109.mail.gq1.yahoo.com>
Message-ID: <87prab9l9k.fsf@clarabella.noc.seabone.net>

:-> "Tony" == Tony  <td_miles at yahoo.com> writes:

    > Hi all,
    > I'm wondering if there is a way to slow down the speed of VTY (telnet) sessions on a Cisco router ?

    > We have the situation that when RANCID grabs a config from an
    > older 7204 with NPE-300 it causes the CPU to hit 100% for a long
    > 4-5 seconds, which is long enough for OSPF with 1 second
    > hello-interval to time out and declare neighbours dead. 


We had a situation in the past where rancid would cause some 72xx and
75xx to crawl and sometime crash when accessing the disks. You
may want to check if that's the case and comment out the offending
command in @commandtable (around line 1700 of /usr/lib/rancid/bin/rancid)

IIRC it depends on IOS version and type of ata disk used.

Pf

-- 


-------------------------------------------------------------------------------
 Pierfrancesco Caci | Network & System Administrator - INOC-DBA: 6762*PFC
 p.caci at seabone.net | Telecom Italia Sparkle - http://etabeta.noc.seabone.net/

From chris.garzon at gmail.com  Tue Sep  1 03:36:39 2009
From: chris.garzon at gmail.com (Dracul)
Date: Tue, 1 Sep 2009 15:36:39 +0800
Subject: [c-nsp] some WCCP questions
In-Reply-To: <20090901065208.GB7719@skywalker.creative.net.au>
References: <876789290908312347m14a5f8f2n647c4529d95b44de@mail.gmail.com>
	<20090901065208.GB7719@skywalker.creative.net.au>
Message-ID: <876789290909010036w6c167279ieea6d2531ec29853@mail.gmail.com>

Thanks adrian,

>That takes time - the WCCPv2 router will take a while to time out the
>now-unreachable server. It would be possible to hack in some code to try
>sending a last "gasping breath" packet to the WCCPv2 router to say the
>cache is about to disappear, but it won't save existing connections.

So will user in the network , "feel" the turnover of packets like they
would  just have some momentary
lapse of connection (browsing or downloading via http)


On Tue, Sep 1, 2009 at 2:52 PM, Adrian Chadd <adrian at creative.net.au> wrote:

> On Tue, Sep 01, 2009, Dracul wrote:
> > Hi List,
> >
> > I'm planning to setup WCCP + Squid.
>
> Hi!
>
> > If the squid server should be offline or the squid process dies, will the
> > users? port 80 requests automatically redirect to the ?live? internet
> > connection??
>
> Yes!
>
> > Because in old "forced" redirection configurations, if the squid process
> > dies or should the squid server be unreachable for some reason, user will
> > see a browser error.
>
> Indeed.
>
> > >From what I understand with WCCP documentation,  if the squid dies or
> the
> > server is unreachable, the network should automatically redirect the
> users
> > to the gateway, without
>
> That takes time - the WCCPv2 router will take a while to time out the
> now-unreachable server. It would be possible to hack in some code to try
> sending a last "gasping breath" packet to the WCCPv2 router to say the
> cache is about to disappear, but it won't save existing connections.
>
> > any disruption of any kind to their browsing experience. Are my
> assumptions
> > correct? Thanks!
>
>
>
> adrian
>
>
> --
> - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid
> Support -
> - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
>

From gert at greenie.muc.de  Tue Sep  1 03:58:03 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 1 Sep 2009 09:58:03 +0200
Subject: [c-nsp] slow down VTY speed
In-Reply-To: <13508.50650.qm@web110109.mail.gq1.yahoo.com>
References: <13508.50650.qm@web110109.mail.gq1.yahoo.com>
Message-ID: <20090901075803.GO117@greenie.muc.de>

Hi,

On Mon, Aug 31, 2009 at 11:56:41PM -0700, Tony wrote:
> We have the situation that when RANCID grabs a config from an
> older 7204 with NPE-300 it causes the CPU to hit 100% for a long
> 4-5 seconds, which is long enough for OSPF with 1 second hello-interval
> to time out and declare neighbours dead.

The problem is quite likely not the VTY speed, but the time it takes the
router to generate the "ASCII config" from its internal tables.

You yould try tweaking the scheduler, to preempt a process that takes 
so long (something like "scheduler allocate 1500 1000" or so).  Or you
could just "not run 1-second hellos on a NPE300"...

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090901/9389b37c/attachment.bin>

From p.mayers at imperial.ac.uk  Tue Sep  1 04:29:30 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Tue, 01 Sep 2009 09:29:30 +0100
Subject: [c-nsp] instabilities with SXI2?
In-Reply-To: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>
References: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>
Message-ID: <4A9CDB6A.6080607@imperial.ac.uk>

Daniska Tomas wrote:
> TAC was pretty responsive, they have identified this as CSCtb27643.
> It happens in SXI2, both modular and monolithic, and whether in VSS
> or not, just when DFCs are in place. The ddts is not public so ask
> your local team.

FWIW we just ran into this; TAC told me SXI2a would be released "shortly"

From A.L.M.Buxey at lboro.ac.uk  Tue Sep  1 04:53:17 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Tue, 1 Sep 2009 09:53:17 +0100
Subject: [c-nsp] instabilities with SXI2?
In-Reply-To: <4A9CDB6A.6080607@imperial.ac.uk>
References: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>
	<4A9CDB6A.6080607@imperial.ac.uk>
Message-ID: <20090901085317.GC2951@lboro.ac.uk>

Hi,
> Daniska Tomas wrote:
>> TAC was pretty responsive, they have identified this as CSCtb27643.
>> It happens in SXI2, both modular and monolithic, and whether in VSS
>> or not, just when DFCs are in place. The ddts is not public so ask
>> your local team.
>
> FWIW we just ran into this; TAC told me SXI2a would be released "shortly"

shortly, as in reasonably rapidly/soon .... or like SXI3 - in October?

alan

From p.mayers at imperial.ac.uk  Tue Sep  1 05:00:20 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Tue, 01 Sep 2009 10:00:20 +0100
Subject: [c-nsp] instabilities with SXI2?
In-Reply-To: <20090901085317.GC2951@lboro.ac.uk>
References: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>
	<4A9CDB6A.6080607@imperial.ac.uk>
	<20090901085317.GC2951@lboro.ac.uk>
Message-ID: <4A9CE2A4.2060109@imperial.ac.uk>

Alan Buxey wrote:
> Hi,
>> Daniska Tomas wrote:
>>> TAC was pretty responsive, they have identified this as CSCtb27643.
>>> It happens in SXI2, both modular and monolithic, and whether in VSS
>>> or not, just when DFCs are in place. The ddts is not public so ask
>>> your local team.
>> FWIW we just ran into this; TAC told me SXI2a would be released "shortly"
> 
> shortly, as in reasonably rapidly/soon .... or like SXI3 - in October?
> 
> alan

All they said was "shortly". I've enquired as to a more precise date.

From illcritikz at gmail.com  Tue Sep  1 05:47:14 2009
From: illcritikz at gmail.com (Ben Steele)
Date: Tue, 1 Sep 2009 19:47:14 +1000
Subject: [c-nsp] dampening for VPNv4
In-Reply-To: <7db92dcc0908312241w6951ead8x77efa9b781484414@mail.gmail.com>
References: <7db92dcc0908290435s2c9b32eerc64f076eea1f17a2@mail.gmail.com>
	<7db92dcc0908312241w6951ead8x77efa9b781484414@mail.gmail.com>
Message-ID: <4422cf660909010247y324ab799vae31e03402d6cf3a@mail.gmail.com>

Are you referring to a BGP session between your PE and a CE or the MP-BGP
session between your PE's?
Either way I don't think aggressive dampening is a good idea and is just a
bandaid to the real underlying problem, you have instability inside your
vrf's IGP, this may be due to link flapping, poor summarization,
mis-configuration etc..

You need to address the issue of why you are seeing an unusual amount of
updates, i've setup mpls vpns with 100+ CE's in a single domain with no
excessive BGP update problem - unless there was an actual fault in the vrf
IGP which was causing the BGP updates.

Ben

On Tue, Sep 1, 2009 at 3:41 PM, Ved Labs <vedlabs at gmail.com> wrote:

> Hi Team ,
>
>  any comments on this .
>
> Thanks,
> Ved.
>
> On Sat, Aug 29, 2009 at 5:05 PM, Ved Labs <vedlabs at gmail.com> wrote:
>
> > I would like to know the pros and cons for enabling the dampening for
> VPNv4
> > .
> >
> > I can see a lot of vpnv4 routes flapping and causing the cpu shoot .
> >
> > Thanks,
> > Ved.
> >
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From chris.garzon at gmail.com  Tue Sep  1 06:00:07 2009
From: chris.garzon at gmail.com (Dracul)
Date: Tue, 1 Sep 2009 18:00:07 +0800
Subject: [c-nsp] some WCCP questions
In-Reply-To: <876789290909010036w6c167279ieea6d2531ec29853@mail.gmail.com>
References: <876789290908312347m14a5f8f2n647c4529d95b44de@mail.gmail.com>
	<20090901065208.GB7719@skywalker.creative.net.au>
	<876789290909010036w6c167279ieea6d2531ec29853@mail.gmail.com>
Message-ID: <876789290909010300v4f343abcla722be4a368e0cf5@mail.gmail.com>

Hi,

Followup question regarding WCCP.

How long does it take to refresh cached data in squid? Will wccp be able to
detect if the cached data is already a few hours old? Lets say
for news websites that are cached. Thanks!

regards,
Chris

On Tue, Sep 1, 2009 at 3:36 PM, Dracul <chris.garzon at gmail.com> wrote:

> Thanks adrian,
>
> >That takes time - the WCCPv2 router will take a while to time out the
> >now-unreachable server. It would be possible to hack in some code to try
> >sending a last "gasping breath" packet to the WCCPv2 router to say the
> >cache is about to disappear, but it won't save existing connections.
>
> So will user in the network , "feel" the turnover of packets like they
> would  just have some momentary
> lapse of connection (browsing or downloading via http)
>
>
>
> On Tue, Sep 1, 2009 at 2:52 PM, Adrian Chadd <adrian at creative.net.au>wrote:
>
>> On Tue, Sep 01, 2009, Dracul wrote:
>> > Hi List,
>> >
>> > I'm planning to setup WCCP + Squid.
>>
>> Hi!
>>
>> > If the squid server should be offline or the squid process dies, will
>> the
>> > users? port 80 requests automatically redirect to the ?live? internet
>> > connection??
>>
>> Yes!
>>
>> > Because in old "forced" redirection configurations, if the squid process
>> > dies or should the squid server be unreachable for some reason, user
>> will
>> > see a browser error.
>>
>> Indeed.
>>
>> > >From what I understand with WCCP documentation,  if the squid dies or
>> the
>> > server is unreachable, the network should automatically redirect the
>> users
>> > to the gateway, without
>>
>> That takes time - the WCCPv2 router will take a while to time out the
>> now-unreachable server. It would be possible to hack in some code to try
>> sending a last "gasping breath" packet to the WCCPv2 router to say the
>> cache is about to disappear, but it won't save existing connections.
>>
>> > any disruption of any kind to their browsing experience. Are my
>> assumptions
>> > correct? Thanks!
>>
>>
>>
>> adrian
>>
>>
>> --
>> - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid
>> Support -
>> - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
>>
>
>

From alain.richard at equation.fr  Tue Sep  1 05:38:47 2009
From: alain.richard at equation.fr (Alain RICHARD)
Date: Tue, 1 Sep 2009 11:38:47 +0200
Subject: [c-nsp] ME 6514 and VPLS
Message-ID: <DE1E8168-B818-4B62-8878-02540A9107D0@equation.fr>

Is it extremly difficult to find information about VLPS support on  
cisco products. I would like to build some VPLS configuration and I  
would like to know what kind of VPLS configuration the ME 6524 is able  
to support.

The product brochure indicates "Support H-VPLS architecture, with L2  
access and MPLS access network".

do the ME 6524 support the following commands (they are show as beeing ?

l2 vfi name manual

interface xxx
	xconnect vfi name

if not, what kind of VPLS configuration is it able to support ?

Regards,

-- 
Alain RICHARD


From rubensk at gmail.com  Tue Sep  1 08:57:21 2009
From: rubensk at gmail.com (Rubens Kuhl)
Date: Tue, 1 Sep 2009 09:57:21 -0300
Subject: [c-nsp] ME 6514 and VPLS
In-Reply-To: <DE1E8168-B818-4B62-8878-02540A9107D0@equation.fr>
References: <DE1E8168-B818-4B62-8878-02540A9107D0@equation.fr>
Message-ID: <6bb5f5b10909010557j4f94559au1cfdca5e9cdafdb5@mail.gmail.com>

ME6524 is able to do point-to-point Ethernet L2 circuits (EoMPLS), not
point-to-multipoint (VPLS). ME6524 can be part of a H-VPLS hierarchy
as a leaf, not as a node, which is very similar to do point-to-point
because the multipoint decisions are made on th node.


Rubens




On Tue, Sep 1, 2009 at 6:38 AM, Alain RICHARD<alain.richard at equation.fr> wrote:
> Is it extremly difficult to find information about VLPS support on cisco
> products. I would like to build some VPLS configuration and I would like to
> know what kind of VPLS configuration the ME 6524 is able to support.
>
> The product brochure indicates "Support H-VPLS architecture, with L2 access
> and MPLS access network".
>
> do the ME 6524 support the following commands (they are show as beeing ?
>
> l2 vfi name manual
>
> interface xxx
> ? ? ? ?xconnect vfi name
>
> if not, what kind of VPLS configuration is it able to support ?
>
> Regards,
>
> --
> Alain RICHARD
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From brun0_filipe at yahoo.com  Tue Sep  1 08:22:02 2009
From: brun0_filipe at yahoo.com (Bruno Filipe)
Date: Tue, 1 Sep 2009 05:22:02 -0700 (PDT)
Subject: [c-nsp] interfaces flapping QinQ and/or spanning tree
Message-ID: <684208.86900.qm@web39701.mail.mud.yahoo.com>

Hi there,...

Something Weird is happening to me...the setup is very simple (there's nothing fancy) but for some reason I do have my switch ports flapping all the time and due to the fact the spanning tree is busy converging whenever that happens causing lot of problems...

Have you guys ever faced a problem similar to this?? What's the way around?

Cisco error message document says misconfiguration...I suspect that there's something to do with QinQ...any idea?

#[PRIMO]
Problem Description: Switch interfaces flapping between them

Syslog OUTPUT
Sep  1 11:37:37 cat1.lda2.ao.isp.net 2045: Sep  1 11:37:17.823 GMT+1:
%SW_MATM-4-MACFLAP_NOTIF: Host 0023.3314.0420 in vlan 291 is flapping
between port Fa0/9 and port Fa0/1
Sep  1 11:37:37 cat1.lda2.isp.net 2046: Sep  1 11:37:17.932 GMT+1:
%SW_MATM-4-MACFLAP_NOTIF: Host 0013.8fb8.cb9d in vlan 292 is flapping
between port Fa0/9 and port Fa0/11


#[SECUNDO]
Partial Network Diagram
                              +-+                                                            802.1Q Trunk
                              | |                                       +-----------+ to Another Base Station
           __  WiMAX (802.16) | |--||                             POP#3 |WS-C3550-24|--------> 
          /  \----------------| |  ||                                   +-----------+ Fa0/3
          \__/                | |  ||                                        /Fa0/7
            |                 +-+  ||                                       /
            |                      ||                                      /-->MicroWave link
+--------+  |                      ||                                     /                    802.1Q Trunk
|Customer|--+                      ||  +-----------+                     /Fa0/9    ___________to Another Base Station
| Router |                         ||--| BreezeMAX | 802.1Q Trunk + ----/-------+ /
+--------+                         ||  |   Base    |--------------|WS-C3560-24TS|/ POP#2
                                       |  Station  |         Fa0/4+--/--\-------+
                                       +-----------+          Fa0/1 /    \Fa0/10
                                                                   /      \
                                                Microwave link <--/        \-->Microwave link  
                                                      to         /          \
                                              Another POP(POP#4)             \Fa1/0/1
                                                                            +-\-----------+    802.1Q Trunk     +----+
                                                                      POP#6 |WS-C3750-24TS|---------------------| PE | 
                                                                            +-------------+ Fa1/0/22      Ge0/0 +----+ 

#[TERTIO]
Interface Configs (relevant):
POP#2
interface FastEthernet0/4
 description Link to BreezeMAX Base Station
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 2,291,800-849
 switchport mode trunk
 switchport nonegotiate
 spanning-tree portfast
 spanning-tree bpdufilter enable
 spanning-tree bpduguard enable
 spanning-tree guard none

interface FastEthernet0/1
 description Backhaul Microwave link to POP#4
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 2
 switchport mode trunk
 no cdp enable
 spanning-tree mst 0-1 cost 100000

interface FastEthernet0/9
 description Backhaul Microwave link to POP#3
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 2
 switchport trunk allowed vlan 2-4094
 switchport mode trunk
 no cdp enable

interface FastEthernet0/10
 description Backhaul Microwave link to POP#6
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 2
 switchport mode trunk

POP#6
interface FastEthernet1/0/1
 description Backhaul Microwave link to POP#2
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
 bandwidth 100000
 load-interval 30
 spanning-tree mst 0-1 cost 100000

interface FastEthernet1/0/22
 description 802.1Q Trunk to PE Router
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
 no cdp enable
 spanning-tree portfast
 spanning-tree bpdufilter enable

PE Router:
interface GigabitEthernet0/0.2910025
 description Connection to Customer XYZ
 encapsulation dot1Q 291 second-dot1q 25
 ip address 192.168.158.241 255.255.255.252
 ip verify unicast source reachable-via rx
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 no cdp enable
 service-policy output reg384

CE Router:
interface FastEthernet0/0
 description Connection to ISP XYZ
 ip address 192.168.158.242 255.255.255.252
::
ip route 0.0.0.0 0.0.0.0 192.168.158.242


Base Station QinQ configuration
ID                                  : 1
Metro Tag                           : 291
Data VLAN Range                     : [20...799]
--------------------------------------------------
ID                                  : 2
Metro Tag                           : 291
Data VLAN Range                     : [830...4094]
--------------------------------------------------


/bruno filipe



      

From ray at oneunified.net  Tue Sep  1 09:12:24 2009
From: ray at oneunified.net (Ray Burkholder)
Date: Tue, 1 Sep 2009 10:12:24 -0300
Subject: [c-nsp] ME 6514 and VPLS
In-Reply-To: <6bb5f5b10909010557j4f94559au1cfdca5e9cdafdb5@mail.gmail.com>
References: <DE1E8168-B818-4B62-8878-02540A9107D0@equation.fr>
	<6bb5f5b10909010557j4f94559au1cfdca5e9cdafdb5@mail.gmail.com>
Message-ID: <00e501ca2b05$d934afa0$8b9e0ee0$@net>

> 
> ME6524 is able to do point-to-point Ethernet L2 circuits (EoMPLS), not
> point-to-multipoint (VPLS). ME6524 can be part of a H-VPLS hierarchy
> as a leaf, not as a node, which is very similar to do point-to-point
> because the multipoint decisions are made on th node.
> 

Going into feature navigator for the ME6524, is shows 12.2(33)SXH5 as being
available with Virtual Private LAN Services (VPLS) which links to
http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.8/mpls/configuration/guid
e/gc38vpls.html as a configuration guide line.

Does that indicate that the ME6524 can indeed be a node?

Ray


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


From p.mayers at imperial.ac.uk  Tue Sep  1 10:23:24 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Tue, 01 Sep 2009 15:23:24 +0100
Subject: [c-nsp] ME 6514 and VPLS
In-Reply-To: <00e501ca2b05$d934afa0$8b9e0ee0$@net>
References: <DE1E8168-B818-4B62-8878-02540A9107D0@equation.fr>	<6bb5f5b10909010557j4f94559au1cfdca5e9cdafdb5@mail.gmail.com>
	<00e501ca2b05$d934afa0$8b9e0ee0$@net>
Message-ID: <4A9D2E5C.5090407@imperial.ac.uk>

Ray Burkholder wrote:
>> ME6524 is able to do point-to-point Ethernet L2 circuits (EoMPLS), not
>> point-to-multipoint (VPLS). ME6524 can be part of a H-VPLS hierarchy
>> as a leaf, not as a node, which is very similar to do point-to-point
>> because the multipoint decisions are made on th node.
>>
> 
> Going into feature navigator for the ME6524, is shows 12.2(33)SXH5 as being
> available with Virtual Private LAN Services (VPLS) which links to
> http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.8/mpls/configuration/guid
> e/gc38vpls.html as a configuration guide line.
> 
> Does that indicate that the ME6524 can indeed be a node?
> 
> Ray
> 
> 

No.

PFC3 hardware lacks the ability to do multipoint.

SXH lists VPLS as a feature because the chassis devices can take WAN 
cards, which do support VPLS.

The ME6524 obviously doesn't take WAN cards, so can't do it.

From bacon at walleyesoftware.com  Tue Sep  1 11:19:16 2009
From: bacon at walleyesoftware.com (Jeff Bacon)
Date: Tue, 1 Sep 2009 10:19:16 -0500
Subject: [c-nsp] spurious NAT "disconnects"
Message-ID: <5A69C25361FED34F83ABF05F5047524505CD86F8@wally.walleyetrading.net>

I have a TAC case open for this, but I'll throw it out to the crowd as
well. 

Cat6500, dual-sup720-3B, SXH4. Two linecards - a 6748-GE-TX (no DFC) and
a 6816A (DFC3). 

The switch acts as a "vendor nexus" - we connect to a bunch of
exchanges, and it's the gateway between us and them. Most of the traffic
is multicast coming in on various 1GB links, but there are also several
outbound TCP connections, of the "stay up all day" type - connect in the
morning, talk all day, shut down at 6PM. 

All of the TCP connections are NATted, generally with a different range
to each different vendor (yes someday it would be nice to present one
public routed space to all of them, but not all of them can handle it
even if). 


Occasionally, it appears as though the 6500 will occasionally "confuse"
one established TCP NAT connection with another.

The effect is such that, given connection 1 between A (inside) port W
and B (outside) port X and connection 2 between C (inside) port Y and D
(outside) port Z, the switch will spontaneously start translating the
incoming packets from B (previously being correctly translated to A port
W) and send them to C port W instead of to A port W. Packets from A to
B, however, will still be translated correctly. 

The result to the hosts involved is that B still receives A's packets, B
still thinks it is sending packets to A... but A doesn't receive
anything, and eventually the socket will time out and die (in various
ways, depending on whether keepalive is set or if there's a heartbeat in
the connection protocol or whatever). 

C gets the packets, but since it is invariably to an invalid port on C,
C sends an RST to B, the switch sees a RST packet from C port W to B
port X, doesn't have a NAT entry for that and presumably says "eh,
what's the point", and the packet just drops. 

No errors of any type from the switch. It just notes the connection
dropping (I have "ip nat trans syslog" set). And it's not all that
common - it does it to one connection every odd few days. 

There are a bunch of NAT entries being created/deleted all the time from
a monitoring host, mostly ICMP watching the far-end hosts. 


This was first seen in 12.2(18)SXF15a on a sup32; I upgraded to
12.2(33)SXH4 and the problem appeared to go away. (however, we also
wrote code to detect dropped connections and restart more gracefully.)
The problem has now appeared on SXH4 on a sup720. Or appears to have;
the symptoms are the same in any event.

Weird, huh? 

I have a sniffer on the inside to watch the traffic streams so I can
capture it happening. The question is, what might I set for debug or
poll from the switch in order to determine what the heck the switch is
thinking when it's doing this? 

-bacon


From pdavis at i2k.com  Tue Sep  1 11:36:25 2009
From: pdavis at i2k.com (Philip Davis)
Date: Tue, 01 Sep 2009 11:36:25 -0400
Subject: [c-nsp] NAT Ager CPU Usage
Message-ID: <4A9D3F79.6020405@i2k.com>

Hello,

  I have a 2621XM that is using more CPU on the NAT aging process that I 
would expect. At this moment that process is sitting around 15% with 
~1700 entries in the NAT translation table. In comparison I have other 
2621XMs at other sites doing 2500+ NAT translations where the NAT ager 
process is using <1% of the CPU. At times the NAT ager will use 50+% of 
the CPU still with relatively few translations. This causes problems.
  Does anyone have any idea why this may be happening?

  Thanks,
Phil

From mulitskiy at acedsl.com  Tue Sep  1 12:17:57 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Tue, 1 Sep 2009 12:17:57 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <4A8615B0.8050202@rollernet.us>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<4A8615B0.8050202@rollernet.us>
Message-ID: <200909011217.57596.mulitskiy@acedsl.com>

Hello,

After a little pause it started happening again and we lost 2 more power supplies 
(this time in servers) during last week.
Can anybody advice on a good organization that could do independent power analysis 
in New York, NY?
Thank you,

Michael


On Friday 14 August 2009 09:56:00 pm you wrote:
> Michael Ulitskiy wrote:
> > Hello,
> > 
> > We have a very strange problem. We have recently changed colo-space provider and since that 
> > we had 4 power supply failures in all kind of cisco equipment within 2 month period.
> > According to colo provider we're receiving "clean" power backed up by UPSes and generator.
> > We're currently have 4 20-amps circuits with APC managed PDUs in them and power supply failures 
> > happened in 3 of them, so I can't blame it to one specific circuit or PDU.
> > There was no environmental warning in the logs of any cisco devices. 
> > I'm completely out of the clues. I'm going to bring it up with our colo-space provider, but I'm afraid
> > they'll need some proof or pointers.
> > Does anybody have any ideas what could be causing this and how I can monitor the specific conditions?
> > Thanks,
> > 
> 
> If you're having power supplies cook off like that for no apparent
> reason, I'd get an independent analysis of the power being fed to my
> outlets.
> 
> ~Seth
> 



From thegameiam at yahoo.com  Tue Sep  1 11:58:56 2009
From: thegameiam at yahoo.com (David Barak)
Date: Tue, 1 Sep 2009 08:58:56 -0700 (PDT)
Subject: [c-nsp] interfaces flapping QinQ and/or spanning tree
In-Reply-To: <684208.86900.qm@web39701.mail.mud.yahoo.com>
References: <684208.86900.qm@web39701.mail.mud.yahoo.com>
Message-ID: <640043.77247.qm@web31813.mail.mud.yahoo.com>

Hi Bruno,


Here's a possibility - some vendors implementations of NIC redundancy in a virtualization environment require the use of non-burned-in NICs.  If the servers are built offline, the automatic MAC address assignment can (and will) pick duplicate NICs.  The solutions are to either build the servers in-situ or to maintain a list of allocated virtual MAC addresses and watch for duplicates.  Good luck,
 
David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com



----- Original Message ----
From: Bruno Filipe <brun0_filipe at yahoo.com>
To: cisco-nsp at puck.nether.net
Sent: Tuesday, September 1, 2009 8:22:02 AM
Subject: [c-nsp] interfaces flapping QinQ and/or spanning tree

Hi there,...

Something Weird is happening to me...the setup is very simple (there's nothing fancy) but for some reason I do have my switch ports flapping all the time and due to the fact the spanning tree is busy converging whenever that happens causing lot of problems...

Have you guys ever faced a problem similar to this?? What's the way around?

Cisco error message document says misconfiguration...I suspect that there's something to do with QinQ...any idea?

#[PRIMO]
Problem Description: Switch interfaces flapping between them

Syslog OUTPUT
Sep  1 11:37:37 cat1.lda2.ao.isp.net 2045: Sep  1 11:37:17.823 GMT+1:
%SW_MATM-4-MACFLAP_NOTIF: Host 0023.3314.0420 in vlan 291 is flapping
between port Fa0/9 and port Fa0/1
Sep  1 11:37:37 cat1.lda2.isp.net 2046: Sep  1 11:37:17.932 GMT+1:
%SW_MATM-4-MACFLAP_NOTIF: Host 0013.8fb8.cb9d in vlan 292 is flapping
between port Fa0/9 and port Fa0/11


#[SECUNDO]
Partial Network Diagram
                              +-+                                                            802.1Q Trunk
                              | |                                       +-----------+ to Another Base Station
           __  WiMAX (802.16) | |--||                             POP#3 |WS-C3550-24|--------> 
          /  \----------------| |  ||                                   +-----------+ Fa0/3
          \__/                | |  ||                                        /Fa0/7
            |                 +-+  ||                                       /
            |                      ||                                      /-->MicroWave link
+--------+  |                      ||                                     /                    802.1Q Trunk
|Customer|--+                      ||  +-----------+                     /Fa0/9    ___________to Another Base Station
| Router |                         ||--| BreezeMAX | 802.1Q Trunk + ----/-------+ /
+--------+                         ||  |   Base    |--------------|WS-C3560-24TS|/ POP#2
                                       |  Station  |         Fa0/4+--/--\-------+
                                       +-----------+          Fa0/1 /    \Fa0/10
                                                                   /      \
                                                Microwave link <--/        \-->Microwave link  
                                                      to         /          \
                                              Another POP(POP#4)             \Fa1/0/1
                                                                            +-\-----------+    802.1Q Trunk     +----+
                                                                      POP#6 |WS-C3750-24TS|---------------------| PE | 
                                                                            +-------------+ Fa1/0/22      Ge0/0 +----+ 

#[TERTIO]
Interface Configs (relevant):
POP#2
interface FastEthernet0/4
description Link to BreezeMAX Base Station
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 2,291,800-849
switchport mode trunk
switchport nonegotiate
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
spanning-tree guard none

interface FastEthernet0/1
description Backhaul Microwave link to POP#4
switchport trunk encapsulation dot1q
switchport trunk native vlan 2
switchport mode trunk
no cdp enable
spanning-tree mst 0-1 cost 100000

interface FastEthernet0/9
description Backhaul Microwave link to POP#3
switchport trunk encapsulation dot1q
switchport trunk native vlan 2
switchport trunk allowed vlan 2-4094
switchport mode trunk
no cdp enable

interface FastEthernet0/10
description Backhaul Microwave link to POP#6
switchport trunk encapsulation dot1q
switchport trunk native vlan 2
switchport mode trunk

POP#6
interface FastEthernet1/0/1
description Backhaul Microwave link to POP#2
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
bandwidth 100000
load-interval 30
spanning-tree mst 0-1 cost 100000

interface FastEthernet1/0/22
description 802.1Q Trunk to PE Router
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
no cdp enable
spanning-tree portfast
spanning-tree bpdufilter enable

PE Router:
interface GigabitEthernet0/0.2910025
description Connection to Customer XYZ
encapsulation dot1Q 291 second-dot1q 25
ip address 192.168.158.241 255.255.255.252
ip verify unicast source reachable-via rx
no ip redirects
no ip unreachables
no ip proxy-arp
no cdp enable
service-policy output reg384

CE Router:
interface FastEthernet0/0
description Connection to ISP XYZ
ip address 192.168.158.242 255.255.255.252
::
ip route 0.0.0.0 0.0.0.0 192.168.158.242


Base Station QinQ configuration
ID                                  : 1
Metro Tag                           : 291
Data VLAN Range                     : [20...799]
--------------------------------------------------
ID                                  : 2
Metro Tag                           : 291
Data VLAN Range                     : [830...4094]
--------------------------------------------------


/bruno filipe



      
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


      

From geoff at pendery.net  Tue Sep  1 13:06:12 2009
From: geoff at pendery.net (Geoffrey Pendery)
Date: Tue, 1 Sep 2009 12:06:12 -0500
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <200909011217.57596.mulitskiy@acedsl.com>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<4A8615B0.8050202@rollernet.us>
	<200909011217.57596.mulitskiy@acedsl.com>
Message-ID: <d6966e4b0909011006o73625al1f31a33006175ce7@mail.gmail.com>

Another odd-ball thing to look for, which has plagued us in a few
locations, is zinc whiskers.
You mention physically moving to a new colo provider, and that your
power is supposed to be clean...
We've had repeated power supply failures because of zinc whiskers in a
few of our sites.

Check out http://en.wikipedia.org/wiki/Zinc_whiskers and Google for
"zinc whiskers".
Probably not your problem, but it's one more weird thing to check.


-Geoff


On Tue, Sep 1, 2009 at 11:17 AM, Michael Ulitskiy<mulitskiy at acedsl.com> wrote:
> Hello,
>
> After a little pause it started happening again and we lost 2 more power supplies
> (this time in servers) during last week.
> Can anybody advice on a good organization that could do independent power analysis
> in New York, NY?
> Thank you,
>
> Michael
>
>
> On Friday 14 August 2009 09:56:00 pm you wrote:
>> Michael Ulitskiy wrote:
>> > Hello,
>> >
>> > We have a very strange problem. We have recently changed colo-space provider and since that
>> > we had 4 power supply failures in all kind of cisco equipment within 2 month period.
>> > According to colo provider we're receiving "clean" power backed up by UPSes and generator.
>> > We're currently have 4 20-amps circuits with APC managed PDUs in them and power supply failures
>> > happened in 3 of them, so I can't blame it to one specific circuit or PDU.
>> > There was no environmental warning in the logs of any cisco devices.
>> > I'm completely out of the clues. I'm going to bring it up with our colo-space provider, but I'm afraid
>> > they'll need some proof or pointers.
>> > Does anybody have any ideas what could be causing this and how I can monitor the specific conditions?
>> > Thanks,
>> >
>>
>> If you're having power supplies cook off like that for no apparent
>> reason, I'd get an independent analysis of the power being fed to my
>> outlets.
>>
>> ~Seth
>>
>
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From sethm at rollernet.us  Tue Sep  1 13:21:26 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 01 Sep 2009 10:21:26 -0700
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <200909011217.57596.mulitskiy@acedsl.com>
References: <200908141604.42069.mulitskiy@acedsl.com>	<4A8615B0.8050202@rollernet.us>
	<200909011217.57596.mulitskiy@acedsl.com>
Message-ID: <4A9D5816.7080002@rollernet.us>

Michael Ulitskiy wrote:
> Hello,
> 
> After a little pause it started happening again and we lost 2 more power supplies 
> (this time in servers) during last week.
> Can anybody advice on a good organization that could do independent power analysis 
> in New York, NY?
> Thank you,
> 

Unfortunately I don't (I'm in Reno, NV). What did your provider have to say?

Also, Gert just posted here about adding a grounding lug to the chassis
solving random reboots. Perhaps you can try that, too. It won't hurt.

~Seth

From eninja at gmail.com  Tue Sep  1 13:32:44 2009
From: eninja at gmail.com (e ninja)
Date: Tue, 1 Sep 2009 10:32:44 -0700
Subject: [c-nsp] Troubleshooting High CPU
In-Reply-To: <228424.23640.qm@web111601.mail.gq1.yahoo.com>
References: <E0369829-18B6-48F0-A304-0021E78BEF3C@gmail.com>
	<228424.23640.qm@web111601.mail.gq1.yahoo.com>
Message-ID: <e8590f60909011032g6efa04d5tc8f7e66809b890f@mail.gmail.com>

*Response inline in italics...*

On Mon, Aug 31, 2009 at 9:45 PM, David Warner
<davidwarner1975 at yahoo.com.au>wrote:

> Hi - Thanks for the feedback.
>
> Yes - same hardware (3845), sw, config and traffic. Just deployed as
> active/standby for HSRP. The chief suspect is the port channel between the
> ESWs but would like to get the info to confirm whether its spanning tree or
> another culprit.
>
> Im unable to get any useful info out the box as when it occurs the CPU
> spikes and hits VTY so unable to get any commands back. Is there anyway to
> reserve a minimum amount of CPU to VTY so we can at least issue the commands
> while the problem is occuring?
>


*Yes. Use scheduler interval 1000 global config command. This will schedule
low priority processes to run every 1000 milliseconds (1s) and provide you
time to run some commands, even when the CPU is at 100%.*

-Eninja



> ------------------------------
> *From:* Eninja <eninja at gmail.com>
> *To:* David Warner <davidwarner1975 at yahoo.com.au>
> *Cc:* "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>; Eninja <
> eninja at gmail.com>
> *Sent:* Tuesday, 1 September, 2009 12:11:07 PM
> *Subject:* Re: [c-nsp] Troubleshooting High CPU
>
> What platform is the device? Are the primary and standby devices the same -
> platform, SW, config, traffic?
>
> During the spike, is the CPU consumed at interrupt or process level?
>
> Grab and send over sh proc cpu, sh align, sh int stat, sh log (if device is
> too unresponsive during failover, have onsite personnel pull out
> traffic-laden cables one by one until device is responsive, grab captures
> before reinserting cable/s).
>
> -Eninja
> PS. Disable console logging
>
>
> On Aug 31, 2009, at 10:46 PM, David Warner <davidwarner1975 at yahoo.com.au>
> wrote:
>
> > Hi All,
> >
> > Just wondering if I can get some advice. We have two routers in a HSRP
> active/standby pair. If ones reloads then the CPU on the other hits 100% and
> crashes. The only way we can recover this is for a field engineer to pull
> all the Ethernet cables out and then, when system is calm, repatch them. We
> access the device via VTY so struggling to actually get any commands in to
> troubleshoot as per the Cisco 'Troubleshooting High CPU Utilization' doc as
> the CPU spikes .
> >
> > Any advice on best way to progress this?
> >
> > Regards, David
> >
> >
> >
> >
> __________________________________________________________________________________
>
>
>
> > Find local businesses and services in your area with Yahoo!7 Local.
> > Get started: http://local.yahoo.com.au
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether..net/mailman/listinfo/cisco-nsp<https://puck.nether.net/mailman/listinfo/cisco-nsp>
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
> ------------------------------
> Find local businesses and services in your area with Yahoo!7 Local. Get
> started<http://au.rd.yahoo.com/search/local/mailtagline/*http://local.yahoo.com.au>
> .
>

From rsm at fast-serv.com  Tue Sep  1 13:33:55 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 1 Sep 2009 13:33:55 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <4A9D5816.7080002@rollernet.us>
References: <200908141604.42069.mulitskiy@acedsl.com>	<4A8615B0.8050202@rollernet.us>
	<200909011217.57596.mulitskiy@acedsl.com>
	<4A9D5816.7080002@rollernet.us>
Message-ID: <20090901173318.M29087@fast-serv.com>

Move out ASAP.  You're going to lose many more servers/routers before the
issue is finally identified, and even more before it is remedied (if it ever is).

--
Randy

---------- Original Message -----------
From: Seth Mattinen <sethm at rollernet.us>
To: cisco-nsp at puck.nether.net
Sent: Tue, 01 Sep 2009 10:21:26 -0700
Subject: Re: [c-nsp] Multiple power supply failures. Advise needed

> Michael Ulitskiy wrote:
> > Hello,
> > 
> > After a little pause it started happening again and we lost 2 more power
supplies 
> > (this time in servers) during last week.
> > Can anybody advice on a good organization that could do independent power
analysis 
> > in New York, NY?
> > Thank you,
> >
> 
> Unfortunately I don't (I'm in Reno, NV). What did your provider have 
> to say?
> 
> Also, Gert just posted here about adding a grounding lug to the chassis
> solving random reboots. Perhaps you can try that, too. It won't hurt.
> 
> ~Seth
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
------- End of Original Message -------


From mulitskiy at acedsl.com  Tue Sep  1 13:38:54 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Tue, 1 Sep 2009 13:38:54 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <d6966e4b0909011006o73625al1f31a33006175ce7@mail.gmail.com>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<200909011217.57596.mulitskiy@acedsl.com>
	<d6966e4b0909011006o73625al1f31a33006175ce7@mail.gmail.com>
Message-ID: <200909011338.54199.mulitskiy@acedsl.com>

Interesting. Never heard of that. Can I ask you how you found the source of the 
problem and what you did to get it eliminated?

Michael

On Tuesday 01 September 2009 01:06:12 pm Geoffrey Pendery wrote:
> Another odd-ball thing to look for, which has plagued us in a few
> locations, is zinc whiskers.
> You mention physically moving to a new colo provider, and that your
> power is supposed to be clean...
> We've had repeated power supply failures because of zinc whiskers in a
> few of our sites.
> 
> Check out http://en.wikipedia.org/wiki/Zinc_whiskers and Google for
> "zinc whiskers".
> Probably not your problem, but it's one more weird thing to check.
> 
> 
> -Geoff
> 
> 
> On Tue, Sep 1, 2009 at 11:17 AM, Michael Ulitskiy<mulitskiy at acedsl.com> wrote:
> > Hello,
> >
> > After a little pause it started happening again and we lost 2 more power supplies
> > (this time in servers) during last week.
> > Can anybody advice on a good organization that could do independent power analysis
> > in New York, NY?
> > Thank you,
> >
> > Michael
> >
> >
> > On Friday 14 August 2009 09:56:00 pm you wrote:
> >> Michael Ulitskiy wrote:
> >> > Hello,
> >> >
> >> > We have a very strange problem. We have recently changed colo-space provider and since that
> >> > we had 4 power supply failures in all kind of cisco equipment within 2 month period.
> >> > According to colo provider we're receiving "clean" power backed up by UPSes and generator.
> >> > We're currently have 4 20-amps circuits with APC managed PDUs in them and power supply failures
> >> > happened in 3 of them, so I can't blame it to one specific circuit or PDU.
> >> > There was no environmental warning in the logs of any cisco devices.
> >> > I'm completely out of the clues. I'm going to bring it up with our colo-space provider, but I'm afraid
> >> > they'll need some proof or pointers.
> >> > Does anybody have any ideas what could be causing this and how I can monitor the specific conditions?
> >> > Thanks,
> >> >
> >>
> >> If you're having power supplies cook off like that for no apparent
> >> reason, I'd get an independent analysis of the power being fed to my
> >> outlets.
> >>
> >> ~Seth
> >>
> >
> >
> > _______________________________________________
> > cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> 



From gsgranados at comcast.net  Tue Sep  1 13:39:36 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Tue, 1 Sep 2009 10:39:36 -0700
Subject: [c-nsp] Multiple power supply failures. Advise needed
References: <200908141604.42069.mulitskiy@acedsl.com>	<4A8615B0.8050202@rollernet.us><200909011217.57596.mulitskiy@acedsl.com>
	<4A9D5816.7080002@rollernet.us>
Message-ID: <00db01ca2b2b$3fade6f0$2208120a@am.thmulti.com>

Are these random events?  Have you mapped the failures against any sort of 
power testing / maintenance that the provider is conducting?  We used to 
blow power supplies in an XO facility in San Francisco and found out after 
some digging that their power folks were crack smokers, not professionals 
and were the actual cause of the failures  You might also want to make sure 
the backup power is sized properly.  I have a client now that lost several 
6500 supplies after a power failure in the bay area because their UPS system 
went crazy under far to much load.  Sounds like transients to me!

----- Original Message ----- 
From: "Seth Mattinen" <sethm at rollernet.us>
To: <cisco-nsp at puck.nether.net>
Sent: Tuesday, September 01, 2009 10:21 AM
Subject: Re: [c-nsp] Multiple power supply failures. Advise needed


> Michael Ulitskiy wrote:
>> Hello,
>>
>> After a little pause it started happening again and we lost 2 more power 
>> supplies
>> (this time in servers) during last week.
>> Can anybody advice on a good organization that could do independent power 
>> analysis
>> in New York, NY?
>> Thank you,
>>
>
> Unfortunately I don't (I'm in Reno, NV). What did your provider have to 
> say?
>
> Also, Gert just posted here about adding a grounding lug to the chassis
> solving random reboots. Perhaps you can try that, too. It won't hurt.
>
> ~Seth
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From mulitskiy at acedsl.com  Tue Sep  1 13:52:26 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Tue, 1 Sep 2009 13:52:26 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <4A9D5816.7080002@rollernet.us>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<200909011217.57596.mulitskiy@acedsl.com>
	<4A9D5816.7080002@rollernet.us>
Message-ID: <200909011352.26956.mulitskiy@acedsl.com>

Well, they claim they have their engineers checked grounding, wiring, UPSes logs.
They also claim they're doing unintrusive power circuit monitoring and so far found no problems.

As for grounding lug I would gladly add it to 6500 chassis if that was the only problem.
Running it to every piece of equipment which count about 50 pieces at the moment wouldn't be fun at all...
Doh...

Michael

On Tuesday 01 September 2009 01:21:26 pm Seth Mattinen wrote:
> Michael Ulitskiy wrote:
> > Hello,
> > 
> > After a little pause it started happening again and we lost 2 more power supplies 
> > (this time in servers) during last week.
> > Can anybody advice on a good organization that could do independent power analysis 
> > in New York, NY?
> > Thank you,
> > 
> 
> Unfortunately I don't (I'm in Reno, NV). What did your provider have to say?
> 
> Also, Gert just posted here about adding a grounding lug to the chassis
> solving random reboots. Perhaps you can try that, too. It won't hurt.
> 
> ~Seth
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 



From rsm at fast-serv.com  Tue Sep  1 13:55:31 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 1 Sep 2009 13:55:31 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <00db01ca2b2b$3fade6f0$2208120a@am.thmulti.com>
References: <200908141604.42069.mulitskiy@acedsl.com>	<4A8615B0.8050202@rollernet.us><200909011217.57596.mulitskiy@acedsl.com>
	<4A9D5816.7080002@rollernet.us>
	<00db01ca2b2b$3fade6f0$2208120a@am.thmulti.com>
Message-ID: <20090901175500.M16793@fast-serv.com>

I second transients (in other words, major voltage spikes).  

My previous reply stands.

Good luck.

--
Randy
www.FastServ.com

---------- Original Message -----------
From: "Scott Granados" <gsgranados at comcast.net>
To: "Seth Mattinen" <sethm at rollernet.us>, <cisco-nsp at puck.nether.net>
Sent: Tue, 1 Sep 2009 10:39:36 -0700
Subject: Re: [c-nsp] Multiple power supply failures. Advise needed

> Are these random events?  Have you mapped the failures against any 
> sort of power testing / maintenance that the provider is conducting? 
>  We used to blow power supplies in an XO facility in San Francisco 
> and found out after some digging that their power folks were crack 
> smokers, not professionals and were the actual cause of the failures 
>  You might also want to make sure the backup power is sized 
> properly.  I have a client now that lost several 6500 supplies after 
> a power failure in the bay area because their UPS system went crazy 
> under far to much load.  Sounds like transients to me!
> 
> ----- Original Message ----- 
> From: "Seth Mattinen" <sethm at rollernet.us>
> To: <cisco-nsp at puck.nether.net>
> Sent: Tuesday, September 01, 2009 10:21 AM
> Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> 
> > Michael Ulitskiy wrote:
> >> Hello,
> >>
> >> After a little pause it started happening again and we lost 2 more power 
> >> supplies
> >> (this time in servers) during last week.
> >> Can anybody advice on a good organization that could do independent power 
> >> analysis
> >> in New York, NY?
> >> Thank you,
> >>
> >
> > Unfortunately I don't (I'm in Reno, NV). What did your provider have to 
> > say?
> >
> > Also, Gert just posted here about adding a grounding lug to the chassis
> > solving random reboots. Perhaps you can try that, too. It won't hurt.
> >
> > ~Seth
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
------- End of Original Message -------


From mulitskiy at acedsl.com  Tue Sep  1 14:12:57 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Tue, 1 Sep 2009 14:12:57 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <00db01ca2b2b$3fade6f0$2208120a@am.thmulti.com>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<4A9D5816.7080002@rollernet.us>
	<00db01ca2b2b$3fade6f0$2208120a@am.thmulti.com>
Message-ID: <200909011412.57617.mulitskiy@acedsl.com>

I forgot to mention that after the 1st wave of failures we have installed tripp lite 
surge protectors on all circuits. These last failures happened with tripp lites installed,
so it shouldn't be transients.

The events are random.  Happened during daytime, night-time, weekdays, weekend. 
I can't see any pattern. 

Moving out is a last recourse which I hate to think about, but sure is an option that's being considered. 
Just been there half a year ago.

Michael

On Tuesday 01 September 2009 01:39:36 pm Scott Granados wrote:
> Are these random events?  Have you mapped the failures against any sort of 
> power testing / maintenance that the provider is conducting?  We used to 
> blow power supplies in an XO facility in San Francisco and found out after 
> some digging that their power folks were crack smokers, not professionals 
> and were the actual cause of the failures  You might also want to make sure 
> the backup power is sized properly.  I have a client now that lost several 
> 6500 supplies after a power failure in the bay area because their UPS system 
> went crazy under far to much load.  Sounds like transients to me!
> 
> ----- Original Message ----- 
> From: "Seth Mattinen" <sethm at rollernet.us>
> To: <cisco-nsp at puck.nether.net>
> Sent: Tuesday, September 01, 2009 10:21 AM
> Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> 
> 
> > Michael Ulitskiy wrote:
> >> Hello,
> >>
> >> After a little pause it started happening again and we lost 2 more power 
> >> supplies
> >> (this time in servers) during last week.
> >> Can anybody advice on a good organization that could do independent power 
> >> analysis
> >> in New York, NY?
> >> Thank you,
> >>
> >
> > Unfortunately I don't (I'm in Reno, NV). What did your provider have to 
> > say?
> >
> > Also, Gert just posted here about adding a grounding lug to the chassis
> > solving random reboots. Perhaps you can try that, too. It won't hurt.
> >
> > ~Seth
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/ 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 



From drew.weaver at thenap.com  Tue Sep  1 14:10:22 2009
From: drew.weaver at thenap.com (Drew Weaver)
Date: Tue, 1 Sep 2009 14:10:22 -0400
Subject: [c-nsp] Monitoring CPU usage on a Sup720-3BXL (BGP)
Message-ID: <F3318834F1F89D46857972DD4B411D70B0070F28@EXCHANGE.thenap.com>

                Hey there,

We've probably all seen this issue before, with BGP scanner eating up a large amount of CPU time on a powerful supervisor/route processor, etc. My question is, how are you supposed to accurately monitor the performance/utilization of the system when this thing is pushing it up to 80% on a regular basis, alternatively, does anyone know if they're ever going to release a product that doesn't have this quirk? its been doing this since the days of the 7500 /w VIP2-50s (as far as I know).

-Drew


From bhabarnaba at gmail.com  Tue Sep  1 14:49:28 2009
From: bhabarnaba at gmail.com (Bhabarnaba Das)
Date: Wed, 2 Sep 2009 00:19:28 +0530
Subject: [c-nsp] Leaking specific routes from a VRF
Message-ID: <9445a3fb0909011149p1e744ecatf30cf3434d92aa2e@mail.gmail.com>

Hi all,

In a working MPLS VPN scenario, is it possible to import and export specific
routes between different VRFs?

For example, if I have two VRFs, VRF1 and VRF2 and I want a particular route
from VRF2 in VRF1, is there a way to import that specific route without
importing all other routes from VRF2 into VRF1?

I am asking this because I guess, a plain import and export of the
respective RTs will lead to an exchange of all the routes present in the two
VRFs, whereas I only require a route to a specific destination.

Of course, the similar treatment has to be given to VRF2 such that the
reverse traffic is possible between two specific IP addresses/subnets in the
two VRFs.

Thanks.

Bhabarnaba

From justin at justinshore.com  Tue Sep  1 15:19:50 2009
From: justin at justinshore.com (Justin Shore)
Date: Tue, 01 Sep 2009 14:19:50 -0500
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <200909011352.26956.mulitskiy@acedsl.com>
References: <200908141604.42069.mulitskiy@acedsl.com>	<200909011217.57596.mulitskiy@acedsl.com>	<4A9D5816.7080002@rollernet.us>
	<200909011352.26956.mulitskiy@acedsl.com>
Message-ID: <4A9D73D6.8000409@justinshore.com>

Michael Ulitskiy wrote:
> As for grounding lug I would gladly add it to 6500 chassis if that was the only problem.
> Running it to every piece of equipment which count about 50 pieces at the moment wouldn't be fun at all...
> Doh...

I hate to say it, but the devices shouldn't have gone into production if 
the installation wasn't complete.  Proper grounding is part of a correct 
installation.  I can't count the number of network engineers I've worked 
with over the years that did absolutely no grounding whatsoever.  I can 
name 1 engineer that will never turn up a device without proper 
grounding; me.  Not to beat a dead horse but perhaps a newbie reading 
the list might take this to heart...

Justin



From mark at noc.mainstreet.net  Tue Sep  1 14:29:21 2009
From: mark at noc.mainstreet.net (Mark Kent)
Date: Tue, 1 Sep 2009 11:29:21 -0700 (PDT)
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <mailman.10436.1251826484.2287.cisco-nsp@puck.nether.net>
	(cisco-nsp-request@puck.nether.net)
References: <mailman.10436.1251826484.2287.cisco-nsp@puck.nether.net>
Message-ID: <200909011829.n81ITLJl009670@mainstreet.net>

>> Check out http://en.wikipedia.org/wiki/Zinc_whiskers and Google for
>> "zinc whiskers".

Or, just as useful to you, check out new-ish research results:

  http://blogs.physicstoday.org/update/2009/05/how-tin-whiskers-grow.html

Note that it is in-plane strain *gradients* that lead to the whisker
growth.  If you were previously working on the strains themselves then
this may be the big break you were looking for.

-mark

From ras at e-gerbil.net  Tue Sep  1 15:28:20 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Tue, 1 Sep 2009 14:28:20 -0500
Subject: [c-nsp] Monitoring CPU usage on a Sup720-3BXL (BGP)
In-Reply-To: <F3318834F1F89D46857972DD4B411D70B0070F28@EXCHANGE.thenap.com>
References: <F3318834F1F89D46857972DD4B411D70B0070F28@EXCHANGE.thenap.com>
Message-ID: <20090901192820.GX51443@gerbil.cluepon.net>

On Tue, Sep 01, 2009 at 02:10:22PM -0400, Drew Weaver wrote:
>                 Hey there,
> 
> We've probably all seen this issue before, with BGP scanner eating up
> a large amount of CPU time on a powerful supervisor/route processor,
> etc. My question is, how are you supposed to accurately monitor the
> performance/utilization of the system when this thing is pushing it up
> to 80% on a regular basis, alternatively, does anyone know if they're
> ever going to release a product that doesn't have this quirk? its been
> doing this since the days of the 7500 /w VIP2-50s (as far as I know).

BGP next-hop tracking helps, but doesn't completely remove the need for 
BGP scanner. I know SRB+ has it, not sure about SXH/SXI/etc or any other 
platforms.

http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_bgp_adv_features.html#wp1056214

Of course this just opens the door for new obscure ways for things to
consume CPU and cause problems. The scheduler in newer IOS like SR is
certainly a lot better, so when something does spike it is less likely
to cause disruptions to the rest of the router. In theory the scheduler
from modular IOS is much better too, but this only comes into play if
the process you care about has actually been broken out and isn't
running under the big ios main process.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From tomas at soitron.com  Tue Sep  1 15:31:52 2009
From: tomas at soitron.com (Daniska Tomas)
Date: Tue, 1 Sep 2009 21:31:52 +0200
Subject: [c-nsp] Leaking specific routes from a VRF
In-Reply-To: <9445a3fb0909011149p1e744ecatf30cf3434d92aa2e@mail.gmail.com>
References: <9445a3fb0909011149p1e744ecatf30cf3434d92aa2e@mail.gmail.com>
Message-ID: <6B43981C32F8464CB24CEE209DA32BD302516F6C@kenya.tronet.as>


> 
> In a working MPLS VPN scenario, is it possible to import and export
> specific
> routes between different VRFs?
> 

You can use a VRF-level export maps to filter on export or to assign
prefix-specific RTs. You can use import maps to filter specific prefixes
on import. Which suits you better depends on your scenario, you have
find which way is the least complex for you.


--

deejay
 

__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4377
(20090828) __________

Tuto spravu preveril ESET NOD32 Antivirus.

http://www.eset.sk
 

From justin at justinshore.com  Tue Sep  1 15:33:47 2009
From: justin at justinshore.com (Justin Shore)
Date: Tue, 01 Sep 2009 14:33:47 -0500
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <200909011412.57617.mulitskiy@acedsl.com>
References: <200908141604.42069.mulitskiy@acedsl.com>	<4A9D5816.7080002@rollernet.us>	<00db01ca2b2b$3fade6f0$2208120a@am.thmulti.com>
	<200909011412.57617.mulitskiy@acedsl.com>
Message-ID: <4A9D771B.7020305@justinshore.com>

Michael Ulitskiy wrote:
> I forgot to mention that after the 1st wave of failures we have installed tripp lite 
> surge protectors on all circuits. These last failures happened with tripp lites installed,
> so it shouldn't be transients.
> 
> The events are random.  Happened during daytime, night-time, weekdays, weekend. 
> I can't see any pattern. 
> 
> Moving out is a last recourse which I hate to think about, but sure is an option that's being considered. 
> Just been there half a year ago.

Here's a little secret about surge protectors.  Most of them flat out 
suck.  Most of them are of no use unless the surge is extremely large 
such as what you'd expect from a lightning strike.  In reality a surge 
protector should clamp down at 150v or less.  I saw a demo once of 
several different brands of surge protectors that we supplied to a 
distributor of another brand.  Most of the ones we'd supplied had 
apparently already been hit and had blown the pot.  A few were actually 
good.  200+ volts passing through them and they still hadn't tripped. 
The APC actually melted in the demo (which explained the concrete board 
they laid on our table under the surge strips).  Then the reseller 
brouht out a Panamax surge protector.  He started walking up the voltage 
from 110.  At around 140v it tripped.  Walked it back down and the surge 
strip came back on.  It doesn't fry itself tripping like most of the 
other brands do.  Then he walked it down from 110v.  At around 90v it 
tripped as well.  It cuts off for under-voltage which is a major problem 
in the rural areas I come from.

http://www.panamax.com/Products/Floor-Models/M8-EX.aspx

I would highly recommend Panamax brand surge protectors to anyone.  Not 
all of them cut off for under-voltage so look at the specs carefully. 
The one I linked to does of course.  It's worth the slight premium to 
buy the good stuff.  I don't buy anything else anymore.  We didn't test 
Tripp Lite so I don't know how they stack up.  For $40 you can be sure 
though with a good Panamax.

One thing that you might consider is placing a decent manageable UPS in 
your rack.  You don't have to put a load on it.  Use it to monitor the 
line condition for irregularities.  Manageable UPSs tend to be much 
cheaper than commercial power quality monitoring equipment.  With that 
data in hand you can approach your colo provider.

Justin



From mulitskiy at acedsl.com  Tue Sep  1 16:13:04 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Tue, 1 Sep 2009 16:13:04 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <4A9D73D6.8000409@justinshore.com>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<200909011352.26956.mulitskiy@acedsl.com>
	<4A9D73D6.8000409@justinshore.com>
Message-ID: <200909011613.05194.mulitskiy@acedsl.com>

Sure, but what the proper grounding is? Does it mean that I have to run a 
dedicated grounding wire to every piece of equipment?
The racks are properly grounded (according to provider) and every server is screwed to them. 
The power is provided via NEMA L5-20P twisted lock connecter with proper grounding 
(according to provider). There I currently have tripp lites followed by managed APC PDUs.
All equipment is plugged in into APC grounded outlet. Does it not qualify for "proper grounding"?

I also personally went there with a voltmeter and check for voltage between metal parts 
per Seth Mattinen suggestion and I found 0 voltage. This may sound silly, but I'm taking any chances.
What else I can do?

Michael

On Tuesday 01 September 2009 03:19:50 pm Justin Shore wrote:
> Michael Ulitskiy wrote:
> > As for grounding lug I would gladly add it to 6500 chassis if that was the only problem.
> > Running it to every piece of equipment which count about 50 pieces at the moment wouldn't be fun at all...
> > Doh...
> 
> I hate to say it, but the devices shouldn't have gone into production if 
> the installation wasn't complete.  Proper grounding is part of a correct 
> installation.  I can't count the number of network engineers I've worked 
> with over the years that did absolutely no grounding whatsoever.  I can 
> name 1 engineer that will never turn up a device without proper 
> grounding; me.  Not to beat a dead horse but perhaps a newbie reading 
> the list might take this to heart...
> 
> Justin
> 
> 
> 



From vijay.ramcharan at verizonbusiness.com  Tue Sep  1 15:43:08 2009
From: vijay.ramcharan at verizonbusiness.com (Ramcharan, Vijay A)
Date: Tue, 01 Sep 2009 19:43:08 +0000
Subject: [c-nsp] Leaking specific routes from a VRF
In-Reply-To: <9445a3fb0909011149p1e744ecatf30cf3434d92aa2e@mail.gmail.com>
Message-ID: <8171C8272CE8FE4A8F5BFF8A97CE6AB3016867E4@ASHEVS006.mcilink.com>

You should be able to use an export map, apply a specific route-target
to the desired prefixes and add that specific rt to the destination VRF.



Vijay Ramcharan, CCIE #14824 (RS/SP), CCDP. 
Net. Eng., Verizon Business - ITSGD. 
C: 917-821-8009. 


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Bhabarnaba Das
Sent: Tuesday, September 01, 2009 2:49 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Leaking specific routes from a VRF

Hi all,

In a working MPLS VPN scenario, is it possible to import and export
specific routes between different VRFs?

For example, if I have two VRFs, VRF1 and VRF2 and I want a particular
route from VRF2 in VRF1, is there a way to import that specific route
without importing all other routes from VRF2 into VRF1?

I am asking this because I guess, a plain import and export of the
respective RTs will lead to an exchange of all the routes present in the
two VRFs, whereas I only require a route to a specific destination.

Of course, the similar treatment has to be given to VRF2 such that the
reverse traffic is possible between two specific IP addresses/subnets in
the two VRFs.

Thanks.

Bhabarnaba
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

______________________________________________________________________
This e-mail has been scanned by Verizon Managed Email Content Service,
using Skeptic(tm) technology powered by MessageLabs. For more
information on Verizon Managed Email Content Service, visit
http://www.verizonbusiness.com.
______________________________________________________________________

From rsm at fast-serv.com  Tue Sep  1 16:32:48 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 1 Sep 2009 16:32:48 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <4A9D73D6.8000409@justinshore.com>
References: <200908141604.42069.mulitskiy@acedsl.com>	<200909011217.57596.mulitskiy@acedsl.com>	<4A9D5816.7080002@rollernet.us>
	<200909011352.26956.mulitskiy@acedsl.com>
	<4A9D73D6.8000409@justinshore.com>
Message-ID: <20090901202818.M59336@fast-serv.com>

I'm sorry, but I highly doubt this is why his devices are failing.  Each
device receives ground through the power cord (3rd prong is there for a
reason, as well it is tied to chassis ground internally).  Secondly, the
cabinets themselves should be grounded as is the case in any proper facility.
 By fastening the chasis to the cabinet you are basically providing a second
ground path.  A third ground path is nice and pretty, but it isn't going to do
much if anything at all to help him in this case.

Either the power is extremely dirty, or the facility as a while is not
properly grounded which means no matter how well he grounds his equipment it
won't help unless he digs his own ground.

--
Randy


---------- Original Message -----------
From: Justin Shore <justin at justinshore.com>
To: Michael Ulitskiy <mulitskiy at acedsl.com>
Cc: cisco-nsp at puck.nether.net
Sent: Tue, 01 Sep 2009 14:19:50 -0500
Subject: Re: [c-nsp] Multiple power supply failures. Advise needed

> Michael Ulitskiy wrote:
> > As for grounding lug I would gladly add it to 6500 chassis if that was the
only problem.
> > Running it to every piece of equipment which count about 50 pieces at the
moment wouldn't be fun at all...
> > Doh...
> 
> I hate to say it, but the devices shouldn't have gone into 
> production if the installation wasn't complete.  Proper grounding is 
> part of a correct installation.  I can't count the number of network 
> engineers I've worked with over the years that did absolutely no 
> grounding whatsoever.  I can name 1 engineer that will never turn up 
> a device without proper grounding; me.  Not to beat a dead horse but 
> perhaps a newbie reading the list might take this to heart...
> 
> Justin
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
------- End of Original Message -------


From mulitskiy at acedsl.com  Tue Sep  1 16:35:49 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Tue, 1 Sep 2009 16:35:49 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <200909011829.n81ITLJl009670@mainstreet.net>
References: <mailman.10436.1251826484.2287.cisco-nsp@puck.nether.net>
	<200909011829.n81ITLJl009670@mainstreet.net>
Message-ID: <200909011635.49927.mulitskiy@acedsl.com>

Well, I find the idea with whiskers particularly interesting, because a lot of things 
described are perfectly matched with my situation.
We did recently moved, the data-center does have tiled raised floor (don't know if it zinced though)
and the airflow is bottom to top which probably helps to bring conductive particles like metal dust 
up to the server level where it can be sucked by the power supply fan.
The place is new and we've been the first to occupy it, so we have the longest 
exposure and if this theory is true we should be the most affected and we are.

Now I've spent last hour googling and I can't see what I can do to help it.
Any suggestions?

Michael

On Tuesday 01 September 2009 02:29:21 pm Mark Kent wrote:
> >> Check out http://en.wikipedia.org/wiki/Zinc_whiskers and Google for
> >> "zinc whiskers".
> 
> Or, just as useful to you, check out new-ish research results:
> 
>   http://blogs.physicstoday.org/update/2009/05/how-tin-whiskers-grow.html
> 
> Note that it is in-plane strain *gradients* that lead to the whisker
> growth.  If you were previously working on the strains themselves then
> this may be the big break you were looking for.
> 
> -mark
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 



From rsm at fast-serv.com  Tue Sep  1 16:59:40 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 1 Sep 2009 16:59:40 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <200909011635.49927.mulitskiy@acedsl.com>
References: <mailman.10436.1251826484.2287.cisco-nsp@puck.nether.net>
	<200909011829.n81ITLJl009670@mainstreet.net>
	<200909011635.49927.mulitskiy@acedsl.com>
Message-ID: <20090901205849.M98137@fast-serv.com>

You could pull apart a blown supply and look for them.  According to the wiki
they should be somewhat visible, at least with a magnifying glass.

--
Randy

---------- Original Message -----------
From: Michael Ulitskiy <mulitskiy at acedsl.com>
To: cisco-nsp at puck.nether.net
Sent: Tue, 1 Sep 2009 16:35:49 -0400
Subject: Re: [c-nsp] Multiple power supply failures. Advise needed

> Well, I find the idea with whiskers particularly interesting,
>  because a lot of things described are perfectly matched with my situation.
> We did recently moved, the data-center does have tiled raised floor 
> (don't know if it zinced though) and the airflow is bottom to top 
> which probably helps to bring conductive particles like metal dust 
> up to the server level where it can be sucked by the power supply 
> fan. The place is new and we've been the first to occupy it, so we 
> have the longest exposure and if this theory is true we should be 
> the most affected and we are.
> 
> Now I've spent last hour googling and I can't see what I can do to 
> help it. Any suggestions?
> 
> Michael
> 
> On Tuesday 01 September 2009 02:29:21 pm Mark Kent wrote:
> > >> Check out http://en.wikipedia.org/wiki/Zinc_whiskers and Google for
> > >> "zinc whiskers".
> > 
> > Or, just as useful to you, check out new-ish research results:
> > 
> >   http://blogs.physicstoday.org/update/2009/05/how-tin-whiskers-grow.html
> > 
> > Note that it is in-plane strain *gradients* that lead to the whisker
> > growth.  If you were previously working on the strains themselves then
> > this may be the big break you were looking for.
> > 
> > -mark
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
------- End of Original Message -------


From mulitskiy at acedsl.com  Tue Sep  1 17:27:00 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Tue, 1 Sep 2009 17:27:00 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <20090901205849.M98137@fast-serv.com>
References: <mailman.10436.1251826484.2287.cisco-nsp@puck.nether.net>
	<200909011635.49927.mulitskiy@acedsl.com>
	<20090901205849.M98137@fast-serv.com>
Message-ID: <200909011727.00096.mulitskiy@acedsl.com>

Unless they vaporized by the short.
Unfortunately I don't have those supplies anymore. They're either in the garbage 
or shipped back to vendor for replacement. In any case it would let me make certain 
about the reason for the failures at most (which is sure very important), but the 
important question is what can I do to stop it. I'm still at loss...

Michael

On Tuesday 01 September 2009 04:59:40 pm Randy McAnally wrote:
> You could pull apart a blown supply and look for them.  According to the wiki
> they should be somewhat visible, at least with a magnifying glass.
> 
> --
> Randy
> 
> ---------- Original Message -----------
> From: Michael Ulitskiy <mulitskiy at acedsl.com>
> To: cisco-nsp at puck.nether.net
> Sent: Tue, 1 Sep 2009 16:35:49 -0400
> Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> 
> > Well, I find the idea with whiskers particularly interesting,
> >  because a lot of things described are perfectly matched with my situation.
> > We did recently moved, the data-center does have tiled raised floor 
> > (don't know if it zinced though) and the airflow is bottom to top 
> > which probably helps to bring conductive particles like metal dust 
> > up to the server level where it can be sucked by the power supply 
> > fan. The place is new and we've been the first to occupy it, so we 
> > have the longest exposure and if this theory is true we should be 
> > the most affected and we are.
> > 
> > Now I've spent last hour googling and I can't see what I can do to 
> > help it. Any suggestions?
> > 
> > Michael
> > 
> > On Tuesday 01 September 2009 02:29:21 pm Mark Kent wrote:
> > > >> Check out http://en.wikipedia.org/wiki/Zinc_whiskers and Google for
> > > >> "zinc whiskers".
> > > 
> > > Or, just as useful to you, check out new-ish research results:
> > > 
> > >   http://blogs.physicstoday.org/update/2009/05/how-tin-whiskers-grow.html
> > > 
> > > Note that it is in-plane strain *gradients* that lead to the whisker
> > > growth.  If you were previously working on the strains themselves then
> > > this may be the big break you were looking for.
> > > 
> > > -mark
> > > _______________________________________________
> > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > >
> > 
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> ------- End of Original Message -------
> 
> 



From justin at justinshore.com  Tue Sep  1 18:03:03 2009
From: justin at justinshore.com (Justin Shore)
Date: Tue, 01 Sep 2009 17:03:03 -0500
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <200909011613.05194.mulitskiy@acedsl.com>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<200909011352.26956.mulitskiy@acedsl.com>
	<4A9D73D6.8000409@justinshore.com>
	<200909011613.05194.mulitskiy@acedsl.com>
Message-ID: <4A9D9A17.6050709@justinshore.com>

Unless you scrapped the paint off of every joint between the chassis 
through the mounting brackets to the rack then you aren't guaranteed a 
good connection.  That's why most telco screw kits come with the star 
washer to help scrap the paint of the rack and why most telco equipment 
frames and mounting kits are a non-painted alloy.  Data equipment isn't 
generally made to the same standards.  So for example if you rack up a 
3750 you're using non-painted mounting brackets on a painted 2-post. 
The chassis is also painted so you most likely aren't making a 
connection between the chassis and the bracket and thus not the 2-post.

The ground in the power plane should never be connected within the 
chassis to the chassis itself.  The power plane should never share 
anything common with the chassis.  The chassis should always be grounded 
separately.  Now beyond the panel at the site ground they'll likely meet 
up again but within the powered equipment they should never touch.  Ie, 
the ground conductor in the L5-20R that your colo provider dropped in 
your cage should not internally connect to the chassis of the device. 
The electronics within the device should be insulated from the chassis 
and the chassis should have an external ground connection that you 
connect either to the frame or to a ground bar on the frame.  Depending 
on the equipment (thinking telco for a minute) the equipment is 
sometimes insulated from the frame and connects to a ground bar that is 
also insulated from the frame as well.  There are a lot of telco 
standards out there that are meant for specific applications.  Bottom 
line, always ground the chassis with the supplied hardware either to a 
grounded frame or to a ground bar within the frame that goes back to a 
site ground bar.  Not all manufacturers adhere to those standards though...

Justin


Michael Ulitskiy wrote:
> Sure, but what the proper grounding is? Does it mean that I have to run a 
> dedicated grounding wire to every piece of equipment?
> The racks are properly grounded (according to provider) and every server is screwed to them. 
> The power is provided via NEMA L5-20P twisted lock connecter with proper grounding 
> (according to provider). There I currently have tripp lites followed by managed APC PDUs.
> All equipment is plugged in into APC grounded outlet. Does it not qualify for "proper grounding"?
> 
> I also personally went there with a voltmeter and check for voltage between metal parts 
> per Seth Mattinen suggestion and I found 0 voltage. This may sound silly, but I'm taking any chances.
> What else I can do?


From ed at edgeoc.net  Tue Sep  1 18:06:08 2009
From: ed at edgeoc.net (Edward Salonia)
Date: Tue, 1 Sep 2009 18:06:08 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <200909011727.00096.mulitskiy@acedsl.com>
References: <mailman.10436.1251826484.2287.cisco-nsp@puck.nether.net>
	<200909011635.49927.mulitskiy@acedsl.com>
	<20090901205849.M98137@fast-serv.com>
	<200909011727.00096.mulitskiy@acedsl.com>
Message-ID: <d59dcc10909011506y32423d17l964ef80e6478c29b@mail.gmail.com>

You could look at something like this:
http://www.apc.com/products/resource/include/techspec_index.cfm?base_sku=ACF001

It gets installed in the bottom of the rack to take air from below the
raised floor and blow it up the front of your cabinet. It has a built in
(replaceable) filter, so it will keep any "junk" that is in the floor from
getting blown into your enclosure.

Good Luck.

Edward

On Tue, Sep 1, 2009 at 5:27 PM, Michael Ulitskiy <mulitskiy at acedsl.com>wrote:

> Unless they vaporized by the short.
> Unfortunately I don't have those supplies anymore. They're either in the
> garbage
> or shipped back to vendor for replacement. In any case it would let me make
> certain
> about the reason for the failures at most (which is sure very important),
> but the
> important question is what can I do to stop it. I'm still at loss...
>
> Michael
>
> On Tuesday 01 September 2009 04:59:40 pm Randy McAnally wrote:
> > You could pull apart a blown supply and look for them.  According to the
> wiki
> > they should be somewhat visible, at least with a magnifying glass.
> >
> > --
> > Randy
> >
> > ---------- Original Message -----------
> > From: Michael Ulitskiy <mulitskiy at acedsl.com>
> > To: cisco-nsp at puck.nether.net
> > Sent: Tue, 1 Sep 2009 16:35:49 -0400
> > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> >
> > > Well, I find the idea with whiskers particularly interesting,
> > >  because a lot of things described are perfectly matched with my
> situation.
> > > We did recently moved, the data-center does have tiled raised floor
> > > (don't know if it zinced though) and the airflow is bottom to top
> > > which probably helps to bring conductive particles like metal dust
> > > up to the server level where it can be sucked by the power supply
> > > fan. The place is new and we've been the first to occupy it, so we
> > > have the longest exposure and if this theory is true we should be
> > > the most affected and we are.
> > >
> > > Now I've spent last hour googling and I can't see what I can do to
> > > help it. Any suggestions?
> > >
> > > Michael
> > >
> > > On Tuesday 01 September 2009 02:29:21 pm Mark Kent wrote:
> > > > >> Check out http://en.wikipedia.org/wiki/Zinc_whiskers and Google
> for
> > > > >> "zinc whiskers".
> > > >
> > > > Or, just as useful to you, check out new-ish research results:
> > > >
> > > >
> http://blogs.physicstoday.org/update/2009/05/how-tin-whiskers-grow.html
> > > >
> > > > Note that it is in-plane strain *gradients* that lead to the whisker
> > > > growth.  If you were previously working on the strains themselves
> then
> > > > this may be the big break you were looking for.
> > > >
> > > > -mark
> > > > _______________________________________________
> > > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > >
> > >
> > > _______________________________________________
> > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > ------- End of Original Message -------
> >
> >
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From rsm at fast-serv.com  Tue Sep  1 18:17:11 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 1 Sep 2009 18:17:11 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <200909011727.00096.mulitskiy@acedsl.com>
References: <mailman.10436.1251826484.2287.cisco-nsp@puck.nether.net>
	<200909011635.49927.mulitskiy@acedsl.com>
	<20090901205849.M98137@fast-serv.com>
	<200909011727.00096.mulitskiy@acedsl.com>
Message-ID: <20090901221441.M38677@fast-serv.com>

As another person mentioned, your surge suppressor might not be effective
enough, or perhaps after a couple of surges it was rendered useless.

If you can afford the financial hit, I'd get some large online UPS's for your
equipment that will effectively isolate you from their power.

Although you didn't mention it specifically, are you 100% sure operating temps
in your cabinet are sane?

--
Randy

---------- Original Message -----------
From: Michael Ulitskiy <mulitskiy at acedsl.com>
To: "Randy McAnally" <rsm at fast-serv.com>
Cc: cisco-nsp at puck.nether.net
Sent: Tue, 1 Sep 2009 17:27:00 -0400
Subject: Re: [c-nsp] Multiple power supply failures. Advise needed

> Unless they vaporized by the short.
> Unfortunately I don't have those supplies anymore. They're either in 
> the garbage or shipped back to vendor for replacement. In any case 
> it would let me make certain about the reason for the failures at 
> most (which is sure very important), but the important question is 
> what can I do to stop it. I'm still at loss...
> 
> Michael
> 
> On Tuesday 01 September 2009 04:59:40 pm Randy McAnally wrote:
> > You could pull apart a blown supply and look for them.  According to the wiki
> > they should be somewhat visible, at least with a magnifying glass.
> > 
> > --
> > Randy
> > 
> > ---------- Original Message -----------
> > From: Michael Ulitskiy <mulitskiy at acedsl.com>
> > To: cisco-nsp at puck.nether.net
> > Sent: Tue, 1 Sep 2009 16:35:49 -0400
> > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> > 
> > > Well, I find the idea with whiskers particularly interesting,
> > >  because a lot of things described are perfectly matched with my situation.
> > > We did recently moved, the data-center does have tiled raised floor 
> > > (don't know if it zinced though) and the airflow is bottom to top 
> > > which probably helps to bring conductive particles like metal dust 
> > > up to the server level where it can be sucked by the power supply 
> > > fan. The place is new and we've been the first to occupy it, so we 
> > > have the longest exposure and if this theory is true we should be 
> > > the most affected and we are.
> > > 
> > > Now I've spent last hour googling and I can't see what I can do to 
> > > help it. Any suggestions?
> > > 
> > > Michael
> > > 
> > > On Tuesday 01 September 2009 02:29:21 pm Mark Kent wrote:
> > > > >> Check out http://en.wikipedia.org/wiki/Zinc_whiskers and Google for
> > > > >> "zinc whiskers".
> > > > 
> > > > Or, just as useful to you, check out new-ish research results:
> > > > 
> > > >   http://blogs.physicstoday.org/update/2009/05/how-tin-whiskers-grow.html
> > > > 
> > > > Note that it is in-plane strain *gradients* that lead to the whisker
> > > > growth.  If you were previously working on the strains themselves then
> > > > this may be the big break you were looking for.
> > > > 
> > > > -mark
> > > > _______________________________________________
> > > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > >
> > > 
> > > _______________________________________________
> > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > ------- End of Original Message -------
> > 
> >
------- End of Original Message -------


From eninja at gmail.com  Tue Sep  1 18:56:02 2009
From: eninja at gmail.com (e ninja)
Date: Tue, 1 Sep 2009 15:56:02 -0700
Subject: [c-nsp] Monitoring CPU usage on a Sup720-3BXL (BGP)
In-Reply-To: <F3318834F1F89D46857972DD4B411D70B0070F28@EXCHANGE.thenap.com>
References: <F3318834F1F89D46857972DD4B411D70B0070F28@EXCHANGE.thenap.com>
Message-ID: <e8590f60909011556u3ef0b38dg5436197d3b538338@mail.gmail.com>

Drew,*

Responses inline in italics..*

On Tue, Sep 1, 2009 at 11:10 AM, Drew Weaver <drew.weaver at thenap.com> wrote:

>                Hey there,
>
> We've probably all seen this issue before, with BGP scanner eating up a
> large amount of CPU time on a powerful supervisor/route processor, etc. My
> question is, how are you supposed to accurately monitor the
> performance/utilization of the system when this thing is pushing it up to
> 80% on a regular basis,

*
Baselining. Since you know BGP scanner runs once every minute, only CPUs
spikes that are inconsistent with 'expected' periodic BGP scanner activity
should raise red flags.*



> alternatively, does anyone know if they're ever going to release a product
> that doesn't have this quirk?


*BGP scanner is a housekeeping maintenance activity by the main system
processor. As such, its 'impact' on the 'system' should continue to diminish
as more platforms become modular (distributed architecture) and/or switch
packets in hardware. *

-Eninja

From sethm at rollernet.us  Tue Sep  1 19:26:27 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 01 Sep 2009 16:26:27 -0700
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <20090901202818.M59336@fast-serv.com>
References: <200908141604.42069.mulitskiy@acedsl.com>	<200909011217.57596.mulitskiy@acedsl.com>	<4A9D5816.7080002@rollernet.us>	<200909011352.26956.mulitskiy@acedsl.com>	<4A9D73D6.8000409@justinshore.com>
	<20090901202818.M59336@fast-serv.com>
Message-ID: <4A9DADA3.90909@rollernet.us>

Randy McAnally wrote:
> I'm sorry, but I highly doubt this is why his devices are failing.  Each
> device receives ground through the power cord (3rd prong is there for a
> reason, as well it is tied to chassis ground internally).  Secondly, the
> cabinets themselves should be grounded as is the case in any proper facility.
>  By fastening the chasis to the cabinet you are basically providing a second
> ground path.  A third ground path is nice and pretty, but it isn't going to do
> much if anything at all to help him in this case.
> 
> Either the power is extremely dirty, or the facility as a while is not
> properly grounded which means no matter how well he grounds his equipment it
> won't help unless he digs his own ground.
> 

Correct, the ground is the ground is the ground. The lug will let you
beef it up and do a 6AWG or whatever instead of what's in the power
cords, but the ground is tied everywhere. It has to be; it's a safety
ground.

Something really odd/fishy is going on at the facility in question.
Either they have a problem and won't admit it, or they're just as
baffled as you are. But there is obviously *something* very bad going on
to fry power supplies like that.

Which leads me to a question; has any of the stuff you've replaced
become part of the fried PSU problem, or just originally installed
supplies? One tells me they're lying and the power is even worse than a
raw utility feed, the other says maybe you have metal particles (or
something) building up from under the raised floor over time.

~Seth

From john at vanoppen.com  Tue Sep  1 19:24:36 2009
From: john at vanoppen.com (John van Oppen)
Date: Tue, 1 Sep 2009 16:24:36 -0700
Subject: [c-nsp] Multiple power supply failures. Advise needed
References: <200908141604.42069.mulitskiy@acedsl.com><200909011352.26956.mulitskiy@acedsl.com><4A9D73D6.8000409@justinshore.com><200909011613.05194.mulitskiy@acedsl.com>
	<4A9D9A17.6050709@justinshore.com>
Message-ID: <DB9EA494D2E5614D842C2BC65C2D172288C635@mail-ww.vanoppen.com>

I have never seen a piece of network gear that is AC which does not have
the electrical ground bonded to the chassis, I was under the impression
that bonding is required for safety.    The only time I have ever seen
this is a floating positive side on -48v gear, but even that is not
terribly common.

We have several POPs that are on the tops of hills where we are exposed
to lighting and I can say that not having all of one's grounds bonded is
a really bad idea.   Contrary to popular belief, grounds are not really
required to be at the same potential to the ground but rather to be the
common potential across the entire site, preventing current from flowing
across the data circuits between pieces of gear by providing the lowest
resistance path for any leakage or differentials between the gear.
This common electrical plane is earthed due to safety and static
dissipation reasons since it would be bad from a safety prospective to
have the racks at a different potential than the ground the people are
in the building are standing on (let alone a pain for copper data
circuits).

--John

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Justin Shore
Sent: Tuesday, September 01, 2009 3:03 PM
To: Michael Ulitskiy
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Multiple power supply failures. Advise needed

Unless you scrapped the paint off of every joint between the chassis 
through the mounting brackets to the rack then you aren't guaranteed a 
good connection.  That's why most telco screw kits come with the star 
washer to help scrap the paint of the rack and why most telco equipment 
frames and mounting kits are a non-painted alloy.  Data equipment isn't 
generally made to the same standards.  So for example if you rack up a 
3750 you're using non-painted mounting brackets on a painted 2-post. 
The chassis is also painted so you most likely aren't making a 
connection between the chassis and the bracket and thus not the 2-post.

The ground in the power plane should never be connected within the 
chassis to the chassis itself.  The power plane should never share 
anything common with the chassis.  The chassis should always be grounded

separately.  Now beyond the panel at the site ground they'll likely meet

up again but within the powered equipment they should never touch.  Ie, 
the ground conductor in the L5-20R that your colo provider dropped in 
your cage should not internally connect to the chassis of the device. 
The electronics within the device should be insulated from the chassis 
and the chassis should have an external ground connection that you 
connect either to the frame or to a ground bar on the frame.  Depending 
on the equipment (thinking telco for a minute) the equipment is 
sometimes insulated from the frame and connects to a ground bar that is 
also insulated from the frame as well.  There are a lot of telco 
standards out there that are meant for specific applications.  Bottom 
line, always ground the chassis with the supplied hardware either to a 
grounded frame or to a ground bar within the frame that goes back to a 
site ground bar.  Not all manufacturers adhere to those standards
though...

Justin


Michael Ulitskiy wrote:
> Sure, but what the proper grounding is? Does it mean that I have to
run a 
> dedicated grounding wire to every piece of equipment?
> The racks are properly grounded (according to provider) and every
server is screwed to them. 
> The power is provided via NEMA L5-20P twisted lock connecter with
proper grounding 
> (according to provider). There I currently have tripp lites followed
by managed APC PDUs.
> All equipment is plugged in into APC grounded outlet. Does it not
qualify for "proper grounding"?
> 
> I also personally went there with a voltmeter and check for voltage
between metal parts 
> per Seth Mattinen suggestion and I found 0 voltage. This may sound
silly, but I'm taking any chances.
> What else I can do?

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From gsgranados at comcast.net  Tue Sep  1 20:28:39 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Tue, 1 Sep 2009 17:28:39 -0700
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
Message-ID: <000501ca2b64$54ea36c0$0202fea9@am.thmulti.com>

Hi, I have a Pix out in the field and an ASA5520 that I'm trying to 
configure to pass L2L traffic.  I keep getting an error that says
IKEV1 IP=a.b.c.d removing peer from peer table failed, no match
ip=a.b.c.d unable to remove peer table entry

What am I doing wrong?

Here are the important config bits

asa-5520
crypto map
crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac
crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac
crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac
crypto dynamic-map dynmap 10 set transform-set vpn-transform1 vpn-transform2 
vpn-transform3
crypto dynamic-map dynmap 10 set reverse-route
crypto map vpn-ra-map 10 match address ny-vpn-acl
crypto map vpn-ra-map 10 set peer ny-fw-outside
crypto map vpn-ra-map 10 set transform-set vpn-transform2
crypto map vpn-ra-map 10 set reverse-route
crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap
crypto map vpn-ra-map interface outside

ISAKMP

isakmp enable outside
isakmp policy 5 authentication pre-share
isakmp policy 5 encryption aes-256
isakmp policy 5 hash sha
isakmp policy 5 group 7
isakmp policy 5 lifetime 3600
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption aes-256
isakmp policy 10 hash sha
isakmp policy 10 group 5
isakmp policy 10 lifetime 3600
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 3600
isakmp policy 30 authentication pre-share
isakmp policy 30 encryption aes-192
isakmp policy 30 hash md5
isakmp policy 30 group 2
isakmp policy 30 lifetime 28800
isakmp nat-traversal  20
isakmp reload-wait

and the acl
access-list ny-vpn-acl extended permit ip 10.1.0.0 255.255.0.0 10.18.15.0 
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.18.0.0 255.255.254.0 10.18.15.0 
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.14.0.0 255.254.0.0 10.18.15.0 
255.255.255.192
access-list ny-vpn-acl extended permit ip 157.254.0.0 255.255.0.0 10.18.15.0 
255.255.255.192
access-list ny-vpn-acl extended permit ip 141.11.0.0 255.255.0.0 10.18.15.0 
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.11.0.0 255.255.0.0 10.18.15.0 
255.255.255.192

TUNNEL GROUP

tunnel-group 208.37.161.98 type ipsec-l2l
tunnel-group 208.37.161.98 general-attributes
 tunnel-group 208.37.161.98 ipsec-attributes
 pre-shared-key *
 peer-id-validate nocheck

PIX

CRYPTO MAP and ISAKMP

crypto ipsec transform-set set1 esp-aes-192 esp-md5-hmac
crypto map map1 10 ipsec-isakmp
crypto map map1 10 match address vpn-1
crypto map map1 10 set peer vpnc
crypto map map1 10 set transform-set set1
crypto map map1 interface outside
isakmp enable outside
isakmp key *
 address vpnc netmask 255.255.255.255
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption aes
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 28800

ACL
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0 255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0 
255.255.240.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0 255.254.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0 
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0 
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0 255.255.0.0

)note on the ASA I use individual /24's and shortened the ACL for ease of 
reasing.  I do this to exclued 10.18.14.0/24 from the tunnels since that 
houses the ASA's inside interface and client access)

Any pointers would be appreciated.

Thanks
Scott


From gsgranados at comcast.net  Tue Sep  1 20:35:34 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Tue, 1 Sep 2009 17:35:34 -0700
Subject: [c-nsp] Multiple power supply failures. Advise needed
References: <200908141604.42069.mulitskiy@acedsl.com>	<200909011217.57596.mulitskiy@acedsl.com>	<4A9D5816.7080002@rollernet.us>	<200909011352.26956.mulitskiy@acedsl.com>	<4A9D73D6.8000409@justinshore.com><20090901202818.M59336@fast-serv.com>
	<4A9DADA3.90909@rollernet.us>
Message-ID: <002b01ca2b65$4eda48a0$0202fea9@am.thmulti.com>

Also make sure that the provider isn't doing work in the facility.  I'll 
never forget going to an L3 datacenter and arriving to find workmen in the 
overhead grinding away and dropping dust and who knows what else in to all 
the racks below including a rack of Netra T1's that promptly sucked in the 
dust and kicked out power supplies.;)  It was definitely metal shavings 
because they were using a grinding type tool up in  the over head frames.

----- Original Message ----- 
From: "Seth Mattinen" <sethm at rollernet.us>
To: "Michael Ulitskiy" <mulitskiy at acedsl.com>
Cc: <cisco-nsp at puck.nether.net>
Sent: Tuesday, September 01, 2009 4:26 PM
Subject: Re: [c-nsp] Multiple power supply failures. Advise needed


> Randy McAnally wrote:
>> I'm sorry, but I highly doubt this is why his devices are failing.  Each
>> device receives ground through the power cord (3rd prong is there for a
>> reason, as well it is tied to chassis ground internally).  Secondly, the
>> cabinets themselves should be grounded as is the case in any proper 
>> facility.
>>  By fastening the chasis to the cabinet you are basically providing a 
>> second
>> ground path.  A third ground path is nice and pretty, but it isn't going 
>> to do
>> much if anything at all to help him in this case.
>>
>> Either the power is extremely dirty, or the facility as a while is not
>> properly grounded which means no matter how well he grounds his equipment 
>> it
>> won't help unless he digs his own ground.
>>
>
> Correct, the ground is the ground is the ground. The lug will let you
> beef it up and do a 6AWG or whatever instead of what's in the power
> cords, but the ground is tied everywhere. It has to be; it's a safety
> ground.
>
> Something really odd/fishy is going on at the facility in question.
> Either they have a problem and won't admit it, or they're just as
> baffled as you are. But there is obviously *something* very bad going on
> to fry power supplies like that.
>
> Which leads me to a question; has any of the stuff you've replaced
> become part of the fried PSU problem, or just originally installed
> supplies? One tells me they're lying and the power is even worse than a
> raw utility feed, the other says maybe you have metal particles (or
> something) building up from under the raised floor over time.
>
> ~Seth
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From ras at e-gerbil.net  Tue Sep  1 20:36:23 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Tue, 1 Sep 2009 19:36:23 -0500
Subject: [c-nsp] Monitoring CPU usage on a Sup720-3BXL (BGP)
In-Reply-To: <e8590f60909011556u3ef0b38dg5436197d3b538338@mail.gmail.com>
References: <F3318834F1F89D46857972DD4B411D70B0070F28@EXCHANGE.thenap.com>
	<e8590f60909011556u3ef0b38dg5436197d3b538338@mail.gmail.com>
Message-ID: <20090902003623.GY51443@gerbil.cluepon.net>

On Tue, Sep 01, 2009 at 03:56:02PM -0700, e ninja wrote:
> 
> *BGP scanner is a housekeeping maintenance activity by the main system
> processor. As such, its 'impact' on the 'system' should continue to diminish
> as more platforms become modular (distributed architecture) and/or switch
> packets in hardware. *

Actually no, bgp scanner has nothing to do with platform architecture of 
packet forwarding of any kind (hardware or otherwise). It is an entirely 
software mechanism which periodically walks the entire bgp table and 
does things like verify next-hop reachability. Distributing the 
operations that it performs so that they happen when a prefix or 
next-hop changes is a much better way to handle things (improves 
convergence and reduces the periodic cpu spikes), but you'll probably 
never see it go away completely. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From rsm at fast-serv.com  Tue Sep  1 20:48:38 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 1 Sep 2009 20:48:38 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <002b01ca2b65$4eda48a0$0202fea9@am.thmulti.com>
References: <200908141604.42069.mulitskiy@acedsl.com>	<200909011217.57596.mulitskiy@acedsl.com>	<4A9D5816.7080002@rollernet.us>	<200909011352.26956.mulitskiy@acedsl.com>	<4A9D73D6.8000409@justinshore.com><20090901202818.M59336@fast-serv.com>
	<4A9DADA3.90909@rollernet.us>
	<002b01ca2b65$4eda48a0$0202fea9@am.thmulti.com>
Message-ID: <20090902004658.M47175@fast-serv.com>

He mentioned he was one of the first customers in the colo so
this might be a possibility

--
Randy

---------- Original Message -----------
From: "Scott Granados" <gsgranados at comcast.net>
To: "Seth Mattinen" <sethm at rollernet.us>, "Michael Ulitskiy"
<mulitskiy at acedsl.com>
Cc: cisco-nsp at puck.nether.net
Sent: Tue, 1 Sep 2009 17:35:34 -0700
Subject: Re: [c-nsp] Multiple power supply failures. Advise needed

> Also make sure that the provider isn't doing work in the facility. 
>  I'll never forget going to an L3 datacenter and arriving to find 
> workmen in the overhead grinding away and dropping dust and who 
> knows what else in to all the racks below including a rack of Netra 
> T1's that promptly sucked in the dust and kicked out power 
> supplies.;)  It was definitely metal shavings because they were 
> using a grinding type tool up in  the over head frames.
> 


From eninja at gmail.com  Tue Sep  1 22:33:46 2009
From: eninja at gmail.com (e ninja)
Date: Tue, 1 Sep 2009 19:33:46 -0700
Subject: [c-nsp] Monitoring CPU usage on a Sup720-3BXL (BGP)
In-Reply-To: <20090902003623.GY51443@gerbil.cluepon.net>
References: <F3318834F1F89D46857972DD4B411D70B0070F28@EXCHANGE.thenap.com>
	<e8590f60909011556u3ef0b38dg5436197d3b538338@mail.gmail.com>
	<20090902003623.GY51443@gerbil.cluepon.net>
Message-ID: <e8590f60909011933x6e7fad3ak92a902b62bb33a51@mail.gmail.com>

Richard,

On the contrary, as I stated below, the 'impact' of BGP scanner (a
housekeeping task executed by the main processor) on 'system' performance
will continue to diminish as more platforms become modular (distributed
architecture) and/or switch packets in hardware (i.e, independent of RP and
LC CPU eg in FPGAs)

Nothing in the aforementioned suggests that BGP scanner (a critical process
for validating the integrity of the BGP table) will EoL anytime soon.
Instead, if you note the quotes, Drew is concerned with the impact of the
CPU consumed by BGP scanner on 'system' performance. This concern does not
exist on modular platforms with distributed packet switching (c12k, hfr
etc.) that switch packets independent of main RP CPU. Put simply, even if
BGP scanner maxes out an RP CPU at 100% temporarily on a distributed
platform, it will have zero effect on packet switching (a la 'system' perf)
through the device.

Your thoughts below dwell more on enhancing the mechanism to reduce
frequency.

-Eninja ;-)



On Tue, Sep 1, 2009 at 5:36 PM, Richard A Steenbergen <ras at e-gerbil.net>wrote:

> On Tue, Sep 01, 2009 at 03:56:02PM -0700, e ninja wrote:
> >
> > *BGP scanner is a housekeeping maintenance activity by the main system
> > processor. As such, its 'impact' on the 'system' should continue to
> diminish
> > as more platforms become modular (distributed architecture) and/or switch
> > packets in hardware. *
>
> Actually no, bgp scanner has nothing to do with platform architecture of
> packet forwarding of any kind (hardware or otherwise). It is an entirely
> software mechanism which periodically walks the entire bgp table and
> does things like verify next-hop reachability. Distributing the
> operations that it performs so that they happen when a prefix or
> next-hop changes is a much better way to handle things (improves
> convergence and reduces the periodic cpu spikes), but you'll probably
> never see it go away completely. :)
>
> --
> Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
>

From mksmith at adhost.com  Tue Sep  1 22:39:33 2009
From: mksmith at adhost.com (Michael K. Smith)
Date: Tue, 01 Sep 2009 19:39:33 -0700
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <200909011412.57617.mulitskiy@acedsl.com>
Message-ID: <C6C328F5.A947B%mksmith@adhost.com>

You might also be experiencing a sag, not a spike, where your going below
the rated power input for the supply. These can be as damaging as a spike,
and the surge protectors don't usually catch them - you have to have a line
conditioner in place for that.

Regards,

Mike

On 9/1/09 11:12 AM, "Michael Ulitskiy" <mulitskiy at acedsl.com> wrote:

> I forgot to mention that after the 1st wave of failures we have installed
> tripp lite 
> surge protectors on all circuits. These last failures happened with tripp
> lites installed,
> so it shouldn't be transients.
> 
> The events are random.  Happened during daytime, night-time, weekdays,
> weekend. 
> I can't see any pattern.
> 
> Moving out is a last recourse which I hate to think about, but sure is an
> option that's being considered.
> Just been there half a year ago.
> 
> Michael
> 
> On Tuesday 01 September 2009 01:39:36 pm Scott Granados wrote:
>> Are these random events?  Have you mapped the failures against any sort of
>> power testing / maintenance that the provider is conducting?  We used to
>> blow power supplies in an XO facility in San Francisco and found out after
>> some digging that their power folks were crack smokers, not professionals
>> and were the actual cause of the failures  You might also want to make sure
>> the backup power is sized properly.  I have a client now that lost several
>> 6500 supplies after a power failure in the bay area because their UPS system
>> went crazy under far to much load.  Sounds like transients to me!
>> 
>> ----- Original Message -----
>> From: "Seth Mattinen" <sethm at rollernet.us>
>> To: <cisco-nsp at puck.nether.net>
>> Sent: Tuesday, September 01, 2009 10:21 AM
>> Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
>> 
>> 
>>> Michael Ulitskiy wrote:
>>>> Hello,
>>>> 
>>>> After a little pause it started happening again and we lost 2 more power
>>>> supplies
>>>> (this time in servers) during last week.
>>>> Can anybody advice on a good organization that could do independent power
>>>> analysis
>>>> in New York, NY?
>>>> Thank you,
>>>> 
>>> 
>>> Unfortunately I don't (I'm in Reno, NV). What did your provider have to
>>> say?
>>> 
>>> Also, Gert just posted here about adding a grounding lug to the chassis
>>> solving random reboots. Perhaps you can try that, too. It won't hurt.
>>> 
>>> ~Seth
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>> 
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>> 
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From mulitskiy at acedsl.com  Tue Sep  1 23:00:25 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Tue, 1 Sep 2009 23:00:25 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <4A9D9A17.6050709@justinshore.com>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<200909011613.05194.mulitskiy@acedsl.com>
	<4A9D9A17.6050709@justinshore.com>
Message-ID: <200909012300.25218.mulitskiy@acedsl.com>

Justin,

I'm not going to argue an importance of proper grounding. Also I do want to thank you for your reply.
At this point I really doubt that the problem is grounding related, but I'll definitely keep that in mind.
Also in my experience I've never seen a place where every piece of equipment would have a separate
grounding wire attached to the chassis. As far as I can tell this is a standard procedure: grounded outlet,
grounded racks and equipment screwed to the racks.

Michael

On Tuesday 01 September 2009 06:03:03 pm Justin Shore wrote:
> Unless you scrapped the paint off of every joint between the chassis 
> through the mounting brackets to the rack then you aren't guaranteed a 
> good connection.  That's why most telco screw kits come with the star 
> washer to help scrap the paint of the rack and why most telco equipment 
> frames and mounting kits are a non-painted alloy.  Data equipment isn't 
> generally made to the same standards.  So for example if you rack up a 
> 3750 you're using non-painted mounting brackets on a painted 2-post. 
> The chassis is also painted so you most likely aren't making a 
> connection between the chassis and the bracket and thus not the 2-post.
> 
> The ground in the power plane should never be connected within the 
> chassis to the chassis itself.  The power plane should never share 
> anything common with the chassis.  The chassis should always be grounded 
> separately.  Now beyond the panel at the site ground they'll likely meet 
> up again but within the powered equipment they should never touch.  Ie, 
> the ground conductor in the L5-20R that your colo provider dropped in 
> your cage should not internally connect to the chassis of the device. 
> The electronics within the device should be insulated from the chassis 
> and the chassis should have an external ground connection that you 
> connect either to the frame or to a ground bar on the frame.  Depending 
> on the equipment (thinking telco for a minute) the equipment is 
> sometimes insulated from the frame and connects to a ground bar that is 
> also insulated from the frame as well.  There are a lot of telco 
> standards out there that are meant for specific applications.  Bottom 
> line, always ground the chassis with the supplied hardware either to a 
> grounded frame or to a ground bar within the frame that goes back to a 
> site ground bar.  Not all manufacturers adhere to those standards though...
> 
> Justin
> 
> 
> Michael Ulitskiy wrote:
> > Sure, but what the proper grounding is? Does it mean that I have to run a 
> > dedicated grounding wire to every piece of equipment?
> > The racks are properly grounded (according to provider) and every server is screwed to them. 
> > The power is provided via NEMA L5-20P twisted lock connecter with proper grounding 
> > (according to provider). There I currently have tripp lites followed by managed APC PDUs.
> > All equipment is plugged in into APC grounded outlet. Does it not qualify for "proper grounding"?
> > 
> > I also personally went there with a voltmeter and check for voltage between metal parts 
> > per Seth Mattinen suggestion and I found 0 voltage. This may sound silly, but I'm taking any chances.
> > What else I can do?
> 
> 



From mulitskiy at acedsl.com  Tue Sep  1 23:09:31 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Tue, 1 Sep 2009 23:09:31 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <4A9DADA3.90909@rollernet.us>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<20090901202818.M59336@fast-serv.com> <4A9DADA3.90909@rollernet.us>
Message-ID: <200909012309.31383.mulitskiy@acedsl.com>

On Tuesday 01 September 2009 07:26:27 pm you wrote:
 
> Something really odd/fishy is going on at the facility in question.
> Either they have a problem and won't admit it, or they're just as
> baffled as you are. But there is obviously *something* very bad going on
> to fry power supplies like that.
> 
> Which leads me to a question; has any of the stuff you've replaced
> become part of the fried PSU problem, or just originally installed
> supplies? One tells me they're lying and the power is even worse than a
> raw utility feed, the other says maybe you have metal particles (or
> something) building up from under the raised floor over time.

Out of the 7 failed PSUs 6 was original equipment. One cisco gear (AS5400) has power supply failed twice.
The 2nd failed power supply had been in service like 24-48 hours only before the failure, so may be it was just bad
power supply. I'm leaning toward metal particles build up as a most plausible theory at the point. 
I just don't know how to deal with the problem...

Michael


From mulitskiy at acedsl.com  Tue Sep  1 23:21:23 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Tue, 1 Sep 2009 23:21:23 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <20090902004658.M47175@fast-serv.com>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<002b01ca2b65$4eda48a0$0202fea9@am.thmulti.com>
	<20090902004658.M47175@fast-serv.com>
Message-ID: <200909012321.24055.mulitskiy@acedsl.com>

This is my main suspect now. They are doing work in the facility. 
Not heavy construction, but they do install cages and cabinets for new tenants and
they're definitely using tools that  produce metal dust.
My theory is that because of we've been the 1st customer who moved into that facility
we've been collecting that metal dust for longest and so we're having a lot of problems 
with our equipment. To my knowledge none of our neighbors are having the same problem, 
but none of them have been in the place long enough.
So the question remains: is there any way to fight it/protect from it except from going 
through the huge-huge-huge headache of undertaking another move?

Michael

On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote:
> He mentioned he was one of the first customers in the colo so
> this might be a possibility
> 
> --
> Randy
> 
> ---------- Original Message -----------
> From: "Scott Granados" <gsgranados at comcast.net>
> To: "Seth Mattinen" <sethm at rollernet.us>, "Michael Ulitskiy"
> <mulitskiy at acedsl.com>
> Cc: cisco-nsp at puck.nether.net
> Sent: Tue, 1 Sep 2009 17:35:34 -0700
> Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> 
> > Also make sure that the provider isn't doing work in the facility. 
> >  I'll never forget going to an L3 datacenter and arriving to find 
> > workmen in the overhead grinding away and dropping dust and who 
> > knows what else in to all the racks below including a rack of Netra 
> > T1's that promptly sucked in the dust and kicked out power 
> > supplies.;)  It was definitely metal shavings because they were 
> > using a grinding type tool up in  the over head frames.
> > 
> 
> 



From mulitskiy at acedsl.com  Tue Sep  1 23:30:20 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Tue, 1 Sep 2009 23:30:20 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <20090901221441.M38677@fast-serv.com>
References: <mailman.10436.1251826484.2287.cisco-nsp@puck.nether.net>
	<200909011727.00096.mulitskiy@acedsl.com>
	<20090901221441.M38677@fast-serv.com>
Message-ID: <200909012330.20987.mulitskiy@acedsl.com>

Please see inline

On Tuesday 01 September 2009 06:17:11 pm you wrote:
> As another person mentioned, your surge suppressor might not be effective
> enough, or perhaps after a couple of surges it was rendered useless.
> 
> If you can afford the financial hit, I'd get some large online UPS's for your
> equipment that will effectively isolate you from their power.

That's out of the question. Besides, there's no reason to pay rent in telco-grade colo-facility
that have those large UPSes and backup generator in place if I have to maintain my own UPSes.
 
> Although you didn't mention it specifically, are you 100% sure operating temps
> in your cabinet are sane?

That's about the only thing I'm more or less sure about. This is not a cabinet, but an open cage
with 6 open racks installed. The place is cool and I haven't seen a single environmental alarm
from any cisco device or server sensor.

> --
> Randy
> 
> ---------- Original Message -----------
> From: Michael Ulitskiy <mulitskiy at acedsl.com>
> To: "Randy McAnally" <rsm at fast-serv.com>
> Cc: cisco-nsp at puck.nether.net
> Sent: Tue, 1 Sep 2009 17:27:00 -0400
> Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> 
> > Unless they vaporized by the short.
> > Unfortunately I don't have those supplies anymore. They're either in 
> > the garbage or shipped back to vendor for replacement. In any case 
> > it would let me make certain about the reason for the failures at 
> > most (which is sure very important), but the important question is 
> > what can I do to stop it. I'm still at loss...
> > 
> > Michael
> > 
> > On Tuesday 01 September 2009 04:59:40 pm Randy McAnally wrote:
> > > You could pull apart a blown supply and look for them.  According to the wiki
> > > they should be somewhat visible, at least with a magnifying glass.
> > > 
> > > --
> > > Randy
> > > 
> > > ---------- Original Message -----------
> > > From: Michael Ulitskiy <mulitskiy at acedsl.com>
> > > To: cisco-nsp at puck.nether.net
> > > Sent: Tue, 1 Sep 2009 16:35:49 -0400
> > > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> > > 
> > > > Well, I find the idea with whiskers particularly interesting,
> > > >  because a lot of things described are perfectly matched with my situation.
> > > > We did recently moved, the data-center does have tiled raised floor 
> > > > (don't know if it zinced though) and the airflow is bottom to top 
> > > > which probably helps to bring conductive particles like metal dust 
> > > > up to the server level where it can be sucked by the power supply 
> > > > fan. The place is new and we've been the first to occupy it, so we 
> > > > have the longest exposure and if this theory is true we should be 
> > > > the most affected and we are.
> > > > 
> > > > Now I've spent last hour googling and I can't see what I can do to 
> > > > help it. Any suggestions?
> > > > 
> > > > Michael
> > > > 
> > > > On Tuesday 01 September 2009 02:29:21 pm Mark Kent wrote:
> > > > > >> Check out http://en.wikipedia.org/wiki/Zinc_whiskers and Google for
> > > > > >> "zinc whiskers".
> > > > > 
> > > > > Or, just as useful to you, check out new-ish research results:
> > > > > 
> > > > >   http://blogs.physicstoday.org/update/2009/05/how-tin-whiskers-grow.html
> > > > > 
> > > > > Note that it is in-plane strain *gradients* that lead to the whisker
> > > > > growth.  If you were previously working on the strains themselves then
> > > > > this may be the big break you were looking for.
> > > > > 
> > > > > -mark
> > > > > _______________________________________________
> > > > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > > >
> > > > 
> > > > _______________________________________________
> > > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > ------- End of Original Message -------
> > > 
> > >
> ------- End of Original Message -------
> 
> 



From sethm at rollernet.us  Wed Sep  2 00:12:16 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 01 Sep 2009 21:12:16 -0700
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <200909012309.31383.mulitskiy@acedsl.com>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<20090901202818.M59336@fast-serv.com> <4A9DADA3.90909@rollernet.us>
	<200909012309.31383.mulitskiy@acedsl.com>
Message-ID: <4A9DF0A0.6090004@rollernet.us>

Michael Ulitskiy wrote:
> On Tuesday 01 September 2009 07:26:27 pm you wrote:
>  
>> Something really odd/fishy is going on at the facility in question.
>> Either they have a problem and won't admit it, or they're just as
>> baffled as you are. But there is obviously *something* very bad going on
>> to fry power supplies like that.
>>
>> Which leads me to a question; has any of the stuff you've replaced
>> become part of the fried PSU problem, or just originally installed
>> supplies? One tells me they're lying and the power is even worse than a
>> raw utility feed, the other says maybe you have metal particles (or
>> something) building up from under the raised floor over time.
> 
> Out of the 7 failed PSUs 6 was original equipment. One cisco gear (AS5400) has power supply failed twice.
> The 2nd failed power supply had been in service like 24-48 hours only before the failure, so may be it was just bad
> power supply. I'm leaning toward metal particles build up as a most plausible theory at the point. 
> I just don't know how to deal with the problem...
> 

Yeah, metal dust would be a killer. I don't know what to say either;
magnetic air filters? Maybe salvage/buy some powerful magnets and mount
them in your airflow. See if they collect anything over time. If they
do, at least you'll have evidence.

~Seth

From adrian at creative.net.au  Wed Sep  2 01:23:16 2009
From: adrian at creative.net.au (Adrian Chadd)
Date: Wed, 2 Sep 2009 13:23:16 +0800
Subject: [c-nsp] some WCCP questions
In-Reply-To: <876789290909010300v4f343abcla722be4a368e0cf5@mail.gmail.com>
References: <876789290908312347m14a5f8f2n647c4529d95b44de@mail.gmail.com>
	<20090901065208.GB7719@skywalker.creative.net.au>
	<876789290909010036w6c167279ieea6d2531ec29853@mail.gmail.com>
	<876789290909010300v4f343abcla722be4a368e0cf5@mail.gmail.com>
Message-ID: <20090902052316.GA23682@skywalker.creative.net.au>

On Tue, Sep 01, 2009, Dracul wrote:
> Hi,
> 
> Followup question regarding WCCP.
> 
> How long does it take to refresh cached data in squid? Will wccp be able to
> detect if the cached data is already a few hours old? Lets say
> for news websites that are cached. Thanks!

That's a question for squid-users@, not cisco-nsp. But the answer is
"it depends on the http caching semantics the site presents and how you
have configured squid."



Adrian

> 
> regards,
> Chris
> 
> On Tue, Sep 1, 2009 at 3:36 PM, Dracul <chris.garzon at gmail.com> wrote:
> 
> > Thanks adrian,
> >
> > >That takes time - the WCCPv2 router will take a while to time out the
> > >now-unreachable server. It would be possible to hack in some code to try
> > >sending a last "gasping breath" packet to the WCCPv2 router to say the
> > >cache is about to disappear, but it won't save existing connections.
> >
> > So will user in the network , "feel" the turnover of packets like they
> > would  just have some momentary
> > lapse of connection (browsing or downloading via http)
> >
> >
> >
> > On Tue, Sep 1, 2009 at 2:52 PM, Adrian Chadd <adrian at creative.net.au>wrote:
> >
> >> On Tue, Sep 01, 2009, Dracul wrote:
> >> > Hi List,
> >> >
> >> > I'm planning to setup WCCP + Squid.
> >>
> >> Hi!
> >>
> >> > If the squid server should be offline or the squid process dies, will
> >> the
> >> > users? port 80 requests automatically redirect to the ?live? internet
> >> > connection??
> >>
> >> Yes!
> >>
> >> > Because in old "forced" redirection configurations, if the squid process
> >> > dies or should the squid server be unreachable for some reason, user
> >> will
> >> > see a browser error.
> >>
> >> Indeed.
> >>
> >> > >From what I understand with WCCP documentation,  if the squid dies or
> >> the
> >> > server is unreachable, the network should automatically redirect the
> >> users
> >> > to the gateway, without
> >>
> >> That takes time - the WCCPv2 router will take a while to time out the
> >> now-unreachable server. It would be possible to hack in some code to try
> >> sending a last "gasping breath" packet to the WCCPv2 router to say the
> >> cache is about to disappear, but it won't save existing connections.
> >>
> >> > any disruption of any kind to their browsing experience. Are my
> >> assumptions
> >> > correct? Thanks!
> >>
> >>
> >>
> >> adrian
> >>
> >>
> >> --
> >> - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid
> >> Support -
> >> - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
> >>
> >
> >
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -

From swmike at swm.pp.se  Wed Sep  2 01:26:34 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 2 Sep 2009 07:26:34 +0200 (CEST)
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <4A9DF0A0.6090004@rollernet.us>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<20090901202818.M59336@fast-serv.com> <4A9DADA3.90909@rollernet.us>
	<200909012309.31383.mulitskiy@acedsl.com>
	<4A9DF0A0.6090004@rollernet.us>
Message-ID: <alpine.DEB.1.10.0909020725030.20521@uplift.swm.pp.se>

On Tue, 1 Sep 2009, Seth Mattinen wrote:

> Yeah, metal dust would be a killer. I don't know what to say either; 
> magnetic air filters? Maybe salvage/buy some powerful magnets and mount 
> them in your airflow. See if they collect anything over time. If they 
> do, at least you'll have evidence.

I've heard stories about problems caused by inadequate filtering in sites 
and not really metallic dust but carbon particles/dust from diesel 
engines. When it's enough of it it can help move currents around the 
circuit board that was not intended by the designers...

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se

From td_miles at yahoo.com  Wed Sep  2 03:04:55 2009
From: td_miles at yahoo.com (Tony)
Date: Wed, 2 Sep 2009 00:04:55 -0700 (PDT)
Subject: [c-nsp] slow down VTY speed
In-Reply-To: <87prab9l9k.fsf@clarabella.noc.seabone.net>
Message-ID: <255433.5131.qm@web110109.mail.gq1.yahoo.com>

Hi,

--- On Tue, 1/9/09, Pierfrancesco Caci <p.caci at seabone.net> wrote:
> 
> 
> We had a situation in the past where rancid would cause
> some 72xx and
> 75xx to crawl and sometime crash when accessing the disks..
> You
> may want to check if that's the case and comment out the
> offending
> command in @commandtable (around line 1700 of
> /usr/lib/rancid/bin/rancid)
> 

Thanks for the pointer. I had a look and the @commandtable array contains the following three lines:

 {'more system:running-config'   => 'WriteTerm'},
 {'show running-config'          => 'WriteTerm'},
 {'write term'                   => 'WriteTerm'},

Which I assume are to make sure it can get the config from multiple different types and versions of Cisco devices. All of these commands work on a 7204 (which means it was getting the config three times I think), so I've commented out two of them so it's only executing a single "show run" command.

This seems to have helped quite a lot with the OSPF timeouts. I've cranked up RANCID to run every 10 minutes to flog the poor box to death and see if it will definitely not interfere with OSPF now. If it still does then I'll have to drop back to 2 second hello intervals which should definitely resolve all of the problems.

Thanks for the suggestion of changing the "scheduler allocate" parameters Gert. I went and read some documentation and tried changing it around a bit but it didn't appear to have any beneficial effects at all ?

One thing that I've just discovered that puzzles me is that the OSPF neighbour drops are only on ONE of the links that come into this 7204. It has neighbours on the interfaces Fa0/0.3, Atm1/0.2 & Atm1/0..3. It is only the neighbour on the Fa0/0.3 interface that is dropping, the two connected via ATM are not dropping at all. Is there any logical reason for this ? Is it because I'm using the 10/100 port on the I/O module ? Would it be any different if the ethernet interface was on a PA instead ?


Thanks,
Tony.


      __________________________________________________________________________________
Find local businesses and services in your area with Yahoo!7 Local.
Get started: http://local.yahoo.com.au


From uugnaa_mns at yahoo.com  Wed Sep  2 05:01:33 2009
From: uugnaa_mns at yahoo.com (uugnaa)
Date: Wed, 2 Sep 2009 02:01:33 -0700 (PDT)
Subject: [c-nsp] MCS7816 Communication Manager
Message-ID: <716443.98983.qm@web55102.mail.re4.yahoo.com>

Hello all,

I need your support on this if you may came across it.

Company is planing to deploy IP telephony in the network covering 2 remote sites and head quarter.

here is my plan:

85pcs x CP-3911 (Cisco SIP Phone 3911)
1pcs x MCS7816H3-K9-CMB1 (Unified CM 6.0 7816-H3 Appliance, 0 Seats)
2pcs x LIC-CM-DL-100=
1pcs x LIC-CM6.0-7816= (License Unified CM 6.0 7816 Appliance, 500 seats)

My question is this: 

1. What is the DLU for CP-3911 (Cisco SIP Phone 3911) device?  Based on that I can calculate number of LIC-CM-DL-100= license

2. What is LIC-CM6.0-7816=(License Unified CM 6.0 7816 Appliance, 500 seats) license, is it the one for CM application software license. Because I got this line from the Communication Manager v6.0 documentation. Application and phone software licenses are enforced. 

3. Is there any other LIC-CM6.0-7816= license which has few seats, maybe around 100. By the way, what is a seat here. Seat, does that mean the total number that Comunication manager can manage upto?

4. If I go for Unified CM v7.1 then what is the part number for that with MCS appliance?

thank you in advance.


      

From asturluismi at gmail.com  Wed Sep  2 05:05:22 2009
From: asturluismi at gmail.com (luismi)
Date: Wed, 02 Sep 2009 11:05:22 +0200
Subject: [c-nsp] Leaking specific routes from a VRF
In-Reply-To: <6B43981C32F8464CB24CEE209DA32BD302516F6C@kenya.tronet.as>
References: <9445a3fb0909011149p1e744ecatf30cf3434d92aa2e@mail.gmail.com>
	<6B43981C32F8464CB24CEE209DA32BD302516F6C@kenya.tronet.as>
Message-ID: <1251882322.11377.2.camel@dsba-ipso>

Hi all,

I am interested too in this issue.
Can you send some code as an example to see how it works?


From tomas.caslavsky at gmail.com  Wed Sep  2 05:24:36 2009
From: tomas.caslavsky at gmail.com (Tomas Caslavsky)
Date: Wed, 02 Sep 2009 11:24:36 +0200
Subject: [c-nsp] Leaking specific routes from a VRF
In-Reply-To: <1251882322.11377.2.camel@dsba-ipso>
References: <9445a3fb0909011149p1e744ecatf30cf3434d92aa2e@mail.gmail.com>	<6B43981C32F8464CB24CEE209DA32BD302516F6C@kenya.tronet.as>
	<1251882322.11377.2.camel@dsba-ipso>
Message-ID: <4A9E39D4.7090608@gmail.com>

Hi all,

ip vrf 1204
  rd 11:1157
  export map EXPORT
  route-target export 111:1048

ip prefix-list EXPORTseq 5 deny 0.0.0.0/0
ip prefix-list EXPORT seq 10 permit 84.233.160.160/30

route-map EXPORT permit 10
  match ip address prefix-list EXPORT
  set extcommunity rt  111:1 additive

Regards

Tomas





Dne 02/09/2009 11:05, luismi napsal(a):
> Hi all,
>
> I am interested too in this issue.
> Can you send some code as an example to see how it works?
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>    


From asturluismi at gmail.com  Wed Sep  2 06:47:23 2009
From: asturluismi at gmail.com (luismi)
Date: Wed, 02 Sep 2009 12:47:23 +0200
Subject: [c-nsp] Leaking specific routes from a VRF
In-Reply-To: <4A9E39D4.7090608@gmail.com>
References: <9445a3fb0909011149p1e744ecatf30cf3434d92aa2e@mail.gmail.com>
	<6B43981C32F8464CB24CEE209DA32BD302516F6C@kenya.tronet.as>
	<1251882322.11377.2.camel@dsba-ipso>  <4A9E39D4.7090608@gmail.com>
Message-ID: <1251888443.11377.5.camel@dsba-ipso>

Many thanks :-D


From christopher.varley at zen.co.uk  Wed Sep  2 06:55:44 2009
From: christopher.varley at zen.co.uk (Christopher Varley)
Date: Wed, 2 Sep 2009 11:55:44 +0100
Subject: [c-nsp] Cisco 877w - Unable to NAT traffic for remote IPSec Sites
Message-ID: <ed656be10909020355v3bab0452vaf80fbc110e6bb2a@mail.gmail.com>

Hello All,

I am trying to configure a Cisco 877w to act as a IPSec tunnel
concentrator and provide Internet breakout for the remote sites.The
router is running c870-advsecurityk9-mz.124-15.T5.bin.

The solution currently comprises  of  seven Speedtouch 608WL routers
with the default route set to go over the IPSec tunnel.


ST 608wl  -----IPSec---|                 |
                               | Cisco 877  | --------Internet
ST 608wl  -----IPSec---|                 |


I have configured the IPSec tunnel and I am able to get traffic
between the sites however the Cisco router is not performing NAT for
the remote sites.

The  relevant sections of the configuration are :-

crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
lifetime 3600
crypto isakmp key test123 address 1.1.1.1
crypto isakmp key test123 address 2.2.2.2
crypto isakmp key test123 address 3.3.3.3
crypto isakmp key test123 address 4.4.4.4
crypto isakmp key test123 address 5.5.5.5
crypto isakmp key test123 address 6.6.6.6
crypto isakmp key test123 address 7.7.7.7
!
!
crypto ipsec transform-set TRANSFORM esp-3des esp-md5-hmac
!
crypto map VPN 10 ipsec-isakmp
set peer 1.1.1.1
set transform-set TRANSFORM
set pfs group2
match address 115
crypto map VPN 20 ipsec-isakmp
set peer 2.2.2.2
set transform-set TRANSFORM
set pfs group2
match address 125
crypto map VPN 30 ipsec-isakmp
set peer 3.3.3.3
set transform-set TRANSFORM
set pfs group2
match address 135
crypto map VPN 40 ipsec-isakmp
set peer 4.4.4.4
set transform-set TRANSFORM
set pfs group2
match address 145
crypto map VPN 50 ipsec-isakmp
set peer 5.5.5.5
set transform-set TRANSFORM
set pfs group2
match address 155
crypto map VPN 60 ipsec-isakmp
set peer 6.6.6.6
set transform-set TRANSFORM
set pfs group2
match address 165
crypto map VPN 70 ipsec-isakmp
set peer 7.7.7.7
set transform-set TRANSFORM
set pfs group2
match address 175
!
!
interface Dialer0
ip address negotiated
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer idle-timeout 0
dialer persistent
dialer-group 1
no cdp enable
ppp authentication chap callin
ppp chap hostname xyz123 at abc
ppp chap password 0 xxxxxxx
crypto map VPN
!
!
interface BVI1
description Customer Network
ip address 192.168.20.1 255.255.255.0
ip nat inside
ip virtual-reassembly
!
!
ip route 0.0.0.0 0.0.0.0 Dialer0
!
!
ip nat pool CUST-NATPOOL 82.70.186.30 82.70.186.30 netmask 255.255.255.248
ip nat inside source route-map NONAT pool CUST-NATPOOL overload
!
!
route-map NONAT permit 10
match ip address 110
!
!
access-list 110 deny   ip 192.168.20.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 110 deny   ip 192.168.20.0 0.0.0.255 192.168.2.0 0.0.0.255
access-list 110 deny   ip 192.168.20.0 0.0.0.255 192.168.3.0 0.0.0.255
access-list 110 deny   ip 192.168.20.0 0.0.0.255 192.168.4.0 0.0.0.255
access-list 110 deny   ip 192.168.20.0 0.0.0.255 192.168.5.0 0.0.0.255
access-list 110 deny   ip 192.168.20.0 0.0.0.255 192.168.6.0 0.0.0.255
access-list 110 deny   ip 192.168.20.0 0.0.0.255 192.168.7.0 0.0.0.255
access-list 110 deny   ip 192.168.20.0 0.0.0.255 10.10.0.0 0.0.1.255
access-list 110 permit ip 192.168.0.0 0.0.255.255 any
access-list 115 permit ip any 192.168.1.0 0.0.0.255
access-list 125 permit ip any 192.168.2.0 0.0.0.255
access-list 135 permit ip any 192.168.3.0 0.0.0.255
access-list 145 permit ip any 192.168.4.0 0.0.0.255
access-list 155 permit ip any 192.168.5.0 0.0.0.255
access-list 165 permit ip any 192.168.6.0 0.0.0.255
access-list 175 permit ip any 192.168.7.0 0.0.0.255


I am able see traffic from the spoke sites match ACL 110 permit
statement and also 115 but no entries are created in the NAT table .

Do you have any ideas on where I might be going wrong ?

Regards

Christopher Varley

From A.L.M.Buxey at lboro.ac.uk  Wed Sep  2 07:16:16 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Wed, 2 Sep 2009 12:16:16 +0100
Subject: [c-nsp] do i *need* DFCs on the 6500?
Message-ID: <20090902111616.GA6588@lboro.ac.uk>

hi,

okay, from the background of I know what the DFC is and how it
operates etc... i know I want them - however, I need to justify
the upgrade/part cost to sort out a couple of 6500's.  in some of
our 6500's, the 10G blades have DFCs already...but several 6724's dont
(they just have CFC). ...as i said, I want them, but need to get
some management/funding buy-in - and they dont want the 'what it
does' information - they want some hard and fast facts that Cisco dont
sem to want to tell me ..... so, the question is

1) is there any way of showing the sup720 strain/utilisation...particularly
is there a way of showing DFC usage on the blades where we have them?

2) it offloads IPv6 and QoS - we're into both of those (and more so over the
next year) - any particular insights into QoS performance/issues without
DFC ? any throughput figures for IPv6 ?

(i know that with CFC we're limited to the backplane (32mpps?) and we get ~ 48mpps
per blade with DFC)

...or could it be that DFC's are only really useful to a particular deployment
and I just *think* i need them?  ;-)

alan

From gkg at gmx.de  Wed Sep  2 07:58:25 2009
From: gkg at gmx.de (Garry)
Date: Wed, 02 Sep 2009 13:58:25 +0200
Subject: [c-nsp] VPN traffic to the Internet ...
Message-ID: <4A9E5DE1.7060808@gmx.de>

After trying to get this to work for a while, I'm somewhat out of ideas ...

I have a (otherwise working) VPN-connection from Windows clients (using
Cisco VPN client) to an ASA, IP traffic from and to the internal network
is working just fine. Now the problem comes up that the clients need to
reach a site on the internet that is only accessable from certain IP
ranges, which the mobile clients do not fall into.

I thought, well, no problem, just extend the split tunneling to the
destination IP. So far, so good, the client lists the destination in its
list of tunneled IPs, and traffic to the destination is correctly sent
through the tunnel. It is also correctly decoded on the ASA, but doesn't
seem to go anywhere ...

I've made sure that there's an internal rule allowing any access to that
certain IP. I've also did a tcpdump on the destination to check if maybe
the traffic isn't NATed correctly, but not a single packet is arriving
through the ASA ...

What am I missing here?

Tnx, -garry

From swmike at swm.pp.se  Wed Sep  2 08:04:59 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 2 Sep 2009 14:04:59 +0200 (CEST)
Subject: [c-nsp] do i *need* DFCs on the 6500?
In-Reply-To: <20090902111616.GA6588@lboro.ac.uk>
References: <20090902111616.GA6588@lboro.ac.uk>
Message-ID: <alpine.DEB.1.10.0909021400050.20521@uplift.swm.pp.se>

On Wed, 2 Sep 2009, Alan Buxey wrote:

> 1) is there any way of showing the sup720 
> strain/utilisation...particularly is there a way of showing DFC usage on 
> the blades where we have them?

You're probably thinking of "show mls statistics".

> 2) it offloads IPv6 and QoS - we're into both of those (and more so over the
> next year) - any particular insights into QoS performance/issues without
> DFC ? any throughput figures for IPv6 ?

I'd say that if you're not hitting over 10MPPS on the CFC, you don't 
really need DFC.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se

From rwest at zyedge.com  Wed Sep  2 08:09:28 2009
From: rwest at zyedge.com (Ryan West)
Date: Wed, 2 Sep 2009 08:09:28 -0400
Subject: [c-nsp] VPN traffic to the Internet ...
In-Reply-To: <4A9E5DE1.7060808@gmx.de>
References: <4A9E5DE1.7060808@gmx.de>
Message-ID: <D0E08F7D-D5F1-4276-B2CA-3EEE8BCDC828@zyedge.com>

  nat (outside) 1 VPN range and
Same-security intrainterface.

Sent from handheld.

On Sep 2, 2009, at 8:05 AM, "Garry" <gkg at gmx.de> wrote:

> After trying to get this to work for a while, I'm somewhat out of  
> ideas ...
>
> I have a (otherwise working) VPN-connection from Windows clients  
> (using
> Cisco VPN client) to an ASA, IP traffic from and to the internal  
> network
> is working just fine. Now the problem comes up that the clients need  
> to
> reach a site on the internet that is only accessable from certain IP
> ranges, which the mobile clients do not fall into.
>
> I thought, well, no problem, just extend the split tunneling to the
> destination IP. So far, so good, the client lists the destination in  
> its
> list of tunneled IPs, and traffic to the destination is correctly sent
> through the tunnel. It is also correctly decoded on the ASA, but  
> doesn't
> seem to go anywhere ...
>
> I've made sure that there's an internal rule allowing any access to  
> that
> certain IP. I've also did a tcpdump on the destination to check if  
> maybe
> the traffic isn't NATed correctly, but not a single packet is arriving
> through the ASA ...
>
> What am I missing here?
>
> Tnx, -garry
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From tomas at soitron.com  Wed Sep  2 08:20:47 2009
From: tomas at soitron.com (Daniska, Tomas)
Date: Wed, 2 Sep 2009 14:20:47 +0200
Subject: [c-nsp] SXI, TACACS+ in VRF
Message-ID: <6B43981C32F8464CB24CEE209DA32BD302517107@kenya.tronet.as>

Hi,

anyone using TACACS+ authentication from VRF in SXI successfully? We
have login authentication/authorization working, but for enable
authentication the box somehow fails to connect to the TACACS+ server.

!
aaa group server tacacs+ XXX_tacacs
 server-private x.x.29.142 key ...
 ip vrf forwarding mgmt
 ip tacacs source-interface Loopback1
!
aaa authentication login XXX group XXX_tacacs local
aaa authentication enable default group XXX_tacacs enable
...
!

...
Aug 28 17:00:37.285: AAA/AUTHOR: auth_need : user= 'user' ruser=
'BA_MN1_CO'rem_addr= 'x.x.251.101' priv= 0 list= '' AUTHOR-TYPE=
'command'
Aug 28 17:00:37.285: AAA: parse name=tty2 idb type=-1 tty=-1
Aug 28 17:00:37.285: AAA: name=tty2 flags=0x11 type=5 shelf=0 slot=0
adapter=0 port=2 channel=0
Aug 28 17:00:37.285: AAA/MEMORY: create_user (0xF7E8CF8) user='user'
ruser='NULL' ds0=0 port='tty2' rem_addr='x.x.251.101' authen_type=ASCII
service=ENABLE priv=15 initial_task_id='0', vrf= (id=0)
Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): port='tty2'
list='XXX' action=LOGIN service=ENABLE
Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): using "default" list
Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): Method=XXX_tacacs
(tacacs+)
Aug 28 17:00:37.285: TAC+: send AUTHEN/START packet ver=192 id=-16528696
Aug 28 17:00:37.285: TAC+: Opening TCP/IP to x.x.29.142/49 timeout=5
Aug 28 17:00:37.289: TAC+: TCP/IP open to x.x.29.142/49 failed --
Destination unreachable; gateway or host down
Aug 28 17:00:37.289: AAA/AUTHEN (4278438600): status = ERROR
Aug 28 17:00:37.289: AAA/AUTHEN/START (4278438600): Method=ENABLE
Aug 28 17:00:37.289: AAA/AUTHEN (4278438600): status = GETPASS
Aug 28 17:00:45.021: AAA/AUTHEN/CONT (4278438600): continue_login
(user='(undef)')
Aug 28 17:00:45.021: AAA/AUTHEN (4278438600): status = GETPASS
Aug 28 17:00:45.021: AAA/AUTHEN/CONT (4278438600): Method=ENABLE
Aug 28 17:00:45.025: AAA/AUTHEN (4278438600): password incorrect
Aug 28 17:00:45.025: AAA/AUTHEN (4278438600): status = FAIL


thx

--

deejay


 

__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4388
(20090902) __________

Tuto spravu preveril ESET NOD32 Antivirus.

http://www.eset.sk
 

From justin at justinshore.com  Wed Sep  2 08:39:34 2009
From: justin at justinshore.com (Justin Shore)
Date: Wed, 02 Sep 2009 07:39:34 -0500
Subject: [c-nsp] do i *need* DFCs on the 6500?
In-Reply-To: <20090902111616.GA6588@lboro.ac.uk>
References: <20090902111616.GA6588@lboro.ac.uk>
Message-ID: <4A9E6786.5010901@justinshore.com>

You eluded to one of my strongest selling points on DFCs though I don't 
think you made that particular connection yet.  DFCs offload QoS to the 
LC as you said.  That also means that CoPP is also handled in hardware 
if you have DFCs in place since it requires MLS QoS on that platform. 
Ie, if your 6500/7600 is going to be publicly-accessible on the Internet 
in any capacity and you want it to be able to use CoPP to withstand a 
targeted DoS attack then DFCs are not optional, they're critical.

The others on the list can probably give you much more in-depth views on 
the other aspects of the card but I found CoPP to be a big enough 
selling point.  It wouldn't be good is a simple little DoS attack took 
down my core 7600s.

Justin


Alan Buxey wrote:
> hi,
> 
> okay, from the background of I know what the DFC is and how it
> operates etc... i know I want them - however, I need to justify
> the upgrade/part cost to sort out a couple of 6500's.  in some of
> our 6500's, the 10G blades have DFCs already...but several 6724's dont
> (they just have CFC). ...as i said, I want them, but need to get
> some management/funding buy-in - and they dont want the 'what it
> does' information - they want some hard and fast facts that Cisco dont
> sem to want to tell me ..... so, the question is
> 
> 1) is there any way of showing the sup720 strain/utilisation...particularly
> is there a way of showing DFC usage on the blades where we have them?
> 
> 2) it offloads IPv6 and QoS - we're into both of those (and more so over the
> next year) - any particular insights into QoS performance/issues without
> DFC ? any throughput figures for IPv6 ?
> 
> (i know that with CFC we're limited to the backplane (32mpps?) and we get ~ 48mpps
> per blade with DFC)
> 
> ...or could it be that DFC's are only really useful to a particular deployment
> and I just *think* i need them?  ;-)
> 
> alan
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From peter at rathlev.dk  Wed Sep  2 08:42:31 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Wed, 02 Sep 2009 14:42:31 +0200
Subject: [c-nsp] do i *need* DFCs on the 6500?
In-Reply-To: <alpine.DEB.1.10.0909021400050.20521@uplift.swm.pp.se>
References: <20090902111616.GA6588@lboro.ac.uk>
	<alpine.DEB.1.10.0909021400050.20521@uplift.swm.pp.se>
Message-ID: <1251895351.2991.58.camel@abehat.net.rm.dk>

On Wed, 2009-09-02 at 14:04 +0200, Mikael Abrahamsson wrote:
> On Wed, 2 Sep 2009, Alan Buxey wrote:
> > 2) it offloads IPv6 and QoS - we're into both of those (and more so
> > over the next year) - any particular insights into QoS
> > performance/issues without DFC ? any throughput figures for IPv6 ?
> 
> I'd say that if you're not hitting over 10MPPS on the CFC, you don't 
> really need DFC.

Agreed, and introducing DFCs can give you some headaches with e.g.
policers, since each forwarding engine operates independently from the
others.

Regards,
Peter



From drew.weaver at thenap.com  Wed Sep  2 08:48:22 2009
From: drew.weaver at thenap.com (Drew Weaver)
Date: Wed, 2 Sep 2009 08:48:22 -0400
Subject: [c-nsp] do i *need* DFCs on the 6500?
In-Reply-To: <4A9E6786.5010901@justinshore.com>
References: <20090902111616.GA6588@lboro.ac.uk>
	<4A9E6786.5010901@justinshore.com>
Message-ID: <F3318834F1F89D46857972DD4B411D70B0070F36@EXCHANGE.thenap.com>

Not to thread hijack here, but speaking of withstanding DoS attacks, has anyone seen any decent published baseline configurations for CoPP to deflect things similar to TTL Expiry attacks and the like? Perhaps some sort of template they use (if they can share it) would be really nice.

I would just like to see what others are doing.

-Drew


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Justin Shore
Sent: Wednesday, September 02, 2009 8:40 AM
To: Alan Buxey
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] do i *need* DFCs on the 6500?

You eluded to one of my strongest selling points on DFCs though I don't 
think you made that particular connection yet.  DFCs offload QoS to the 
LC as you said.  That also means that CoPP is also handled in hardware 
if you have DFCs in place since it requires MLS QoS on that platform. 
Ie, if your 6500/7600 is going to be publicly-accessible on the Internet 
in any capacity and you want it to be able to use CoPP to withstand a 
targeted DoS attack then DFCs are not optional, they're critical.

The others on the list can probably give you much more in-depth views on 
the other aspects of the card but I found CoPP to be a big enough 
selling point.  It wouldn't be good is a simple little DoS attack took 
down my core 7600s.

Justin


Alan Buxey wrote:
> hi,
> 
> okay, from the background of I know what the DFC is and how it
> operates etc... i know I want them - however, I need to justify
> the upgrade/part cost to sort out a couple of 6500's.  in some of
> our 6500's, the 10G blades have DFCs already...but several 6724's dont
> (they just have CFC). ...as i said, I want them, but need to get
> some management/funding buy-in - and they dont want the 'what it
> does' information - they want some hard and fast facts that Cisco dont
> sem to want to tell me ..... so, the question is
> 
> 1) is there any way of showing the sup720 strain/utilisation...particularly
> is there a way of showing DFC usage on the blades where we have them?
> 
> 2) it offloads IPv6 and QoS - we're into both of those (and more so over the
> next year) - any particular insights into QoS performance/issues without
> DFC ? any throughput figures for IPv6 ?
> 
> (i know that with CFC we're limited to the backplane (32mpps?) and we get ~ 48mpps
> per blade with DFC)
> 
> ...or could it be that DFC's are only really useful to a particular deployment
> and I just *think* i need them?  ;-)
> 
> alan
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From drew.weaver at thenap.com  Wed Sep  2 08:56:03 2009
From: drew.weaver at thenap.com (Drew Weaver)
Date: Wed, 2 Sep 2009 08:56:03 -0400
Subject: [c-nsp] Monitoring CPU usage on a Sup720-3BXL (BGP)
In-Reply-To: <20090902003623.GY51443@gerbil.cluepon.net>
References: <F3318834F1F89D46857972DD4B411D70B0070F28@EXCHANGE.thenap.com>
	<e8590f60909011556u3ef0b38dg5436197d3b538338@mail.gmail.com>
	<20090902003623.GY51443@gerbil.cluepon.net>
Message-ID: <F3318834F1F89D46857972DD4B411D70B0070F37@EXCHANGE.thenap.com>

Actually no, bgp scanner has nothing to do with platform architecture of 
packet forwarding of any kind (hardware or otherwise). It is an entirely 
software mechanism which periodically walks the entire bgp table and 
does things like verify next-hop reachability. Distributing the 
operations that it performs so that they happen when a prefix or 
next-hop changes is a much better way to handle things (improves 
convergence and reduces the periodic cpu spikes), but you'll probably 
never see it go away completely. :)

--

I didn't assume the actual process BGP scanner would go away, I was simply wondering why as everything (Moore's law) gets much, much faster, this process still has such a impact on the even highest end RPs. I would assume that the "utilization" impact on the RP would go down as the $$$ of the hardware goes up, but I suppose if it all runs in software and isn't using the features of the more expensive RPs then it will just "be slow forever" ;-) I guess you can liken it to a PC without discrete graphics, you can have the best CPU in the world but if you are rendering polys in software, it's still going to chug.

-Drew


From asturluismi at gmail.com  Wed Sep  2 08:56:40 2009
From: asturluismi at gmail.com (luismi)
Date: Wed, 02 Sep 2009 14:56:40 +0200
Subject: [c-nsp] SXI, TACACS+ in VRF
In-Reply-To: <6B43981C32F8464CB24CEE209DA32BD302517107@kenya.tronet.as>
References: <6B43981C32F8464CB24CEE209DA32BD302517107@kenya.tronet.as>
Message-ID: <1251896200.11377.7.camel@dsba-ipso>

did you tried "test aaa" command?


From drew.weaver at thenap.com  Wed Sep  2 09:02:32 2009
From: drew.weaver at thenap.com (Drew Weaver)
Date: Wed, 2 Sep 2009 09:02:32 -0400
Subject: [c-nsp] Monitoring CPU usage on a Sup720-3BXL (BGP)
In-Reply-To: <e8590f60909011933x6e7fad3ak92a902b62bb33a51@mail.gmail.com>
References: <F3318834F1F89D46857972DD4B411D70B0070F28@EXCHANGE.thenap.com>
	<e8590f60909011556u3ef0b38dg5436197d3b538338@mail.gmail.com>
	<20090902003623.GY51443@gerbil.cluepon.net>
	<e8590f60909011933x6e7fad3ak92a902b62bb33a51@mail.gmail.com>
Message-ID: <F3318834F1F89D46857972DD4B411D70B0070F38@EXCHANGE.thenap.com>

e ninja wrote:

Richard,

On the contrary, as I stated below, the 'impact' of BGP scanner (a housekeeping task executed by the main processor) on 'system' performance will continue to diminish as more platforms become modular (distributed architecture) and/or switch packets in hardware (i.e, independent of RP and LC CPU eg in FPGAs)

Nothing in the aforementioned suggests that BGP scanner (a critical process for validating the integrity of the BGP table) will EoL anytime soon. Instead, if you note the quotes, Drew is concerned with the impact of the CPU consumed by BGP scanner on 'system' performance. This concern does not exist on modular platforms with distributed packet switching (c12k, hfr etc.) that switch packets independent of main RP CPU. Put simply, even if BGP scanner maxes out an RP CPU at 100% temporarily on a distributed platform, it will have zero effect on packet switching (a la 'system' perf) through the device.

Your thoughts below dwell more on enhancing the mechanism to reduce frequency.
-------------

Yes, but the confusion in (my mind, anyway) is that sometimes when the RP is at high CPU utilization forwarding performance is affected. i.e. in the case of a DoS attack, although I suppose that the RP being at high CPU utilization is a 'by-product' of the forwarding hardware punting so much crap to the RP and not vice-versa. So when monitoring the CPU for these kinds of events it can be hard to tell in a programmatic way whether it's just BGP scanner, or something more nefarious like a TTL Expiration attack, or any of the other 700 types of DoS/DDoS style attacks which take place these days.

I suppose the real question is, what do you monitor on a modular/distributed system in order to gauge the performance, if not the CPU on the Route Processor? are there OIDs for the discrete switching/forwarding engines? I know at least on the GSR platform each line card has its own CPU/memory statistics available, which is at least ??somewhat?? helpful in quickly identifying a problem.

-Drew

From jared at puck.nether.net  Wed Sep  2 09:03:18 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 2 Sep 2009 09:03:18 -0400
Subject: [c-nsp] do i *need* DFCs on the 6500?
In-Reply-To: <F3318834F1F89D46857972DD4B411D70B0070F36@EXCHANGE.thenap.com>
References: <20090902111616.GA6588@lboro.ac.uk>
	<4A9E6786.5010901@justinshore.com>
	<F3318834F1F89D46857972DD4B411D70B0070F36@EXCHANGE.thenap.com>
Message-ID: <3ACB0F9B-E9C4-4C55-BC83-66EBE868CE86@puck.nether.net>


On Sep 2, 2009, at 8:48 AM, Drew Weaver wrote:

> Not to thread hijack here, but speaking of withstanding DoS attacks,  
> has anyone seen any decent published baseline configurations for  
> CoPP to deflect things similar to TTL Expiry attacks and the like?  
> Perhaps some sort of template they use (if they can share it) would  
> be really nice.

ttl expire can be protected with mls rate limiters. 10 100 seems plenty.

- jared

From rwest at zyedge.com  Wed Sep  2 09:15:57 2009
From: rwest at zyedge.com (Ryan West)
Date: Wed, 2 Sep 2009 09:15:57 -0400
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
In-Reply-To: <000501ca2b64$54ea36c0$0202fea9@am.thmulti.com>
References: <000501ca2b64$54ea36c0$0202fea9@am.thmulti.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248E269EB4@zy-ex1.zyedge.local>

Scott,

Can you provide debugs from the ASA, code versions on both devices and your associated no-nat ACLs?

Assuming you have nothing else logging to monitor, you can enable 'logging class vpn monitor debug' and throw up a term mon to gather inbound messages to the ASA from the PIX side.  You can gather the information on the PIX with a debug cry isa 2 and then initiate interesting traffic from the ASA using the following, the more valuable information will be on the receiving end.  It really doesn't matter which side you enable as the receiver, but I try to stay away from pre 7.x code on the PIXes.

packet-tracer input inside icmp 10.1.0.10 8 0 10.18.15.10 detailed

Phase: 10 or 11 should be subtype encrypt.  If it fails the first time, run it again, the negotiation process causes the first packet to fail as the tunnel is being brought.  This type of traffic will also give you your debug information and help you figure out where the failure is.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Tuesday, September 01, 2009 8:29 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi, I have a Pix out in the field and an ASA5520 that I'm trying to 
configure to pass L2L traffic.  I keep getting an error that says
IKEV1 IP=a.b.c.d removing peer from peer table failed, no match
ip=a.b.c.d unable to remove peer table entry

What am I doing wrong?

Here are the important config bits

asa-5520
crypto map
crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac
crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac
crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac
crypto dynamic-map dynmap 10 set transform-set vpn-transform1 vpn-transform2 
vpn-transform3
crypto dynamic-map dynmap 10 set reverse-route
crypto map vpn-ra-map 10 match address ny-vpn-acl
crypto map vpn-ra-map 10 set peer ny-fw-outside
crypto map vpn-ra-map 10 set transform-set vpn-transform2
crypto map vpn-ra-map 10 set reverse-route
crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap
crypto map vpn-ra-map interface outside

ISAKMP

isakmp enable outside
isakmp policy 5 authentication pre-share
isakmp policy 5 encryption aes-256
isakmp policy 5 hash sha
isakmp policy 5 group 7
isakmp policy 5 lifetime 3600
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption aes-256
isakmp policy 10 hash sha
isakmp policy 10 group 5
isakmp policy 10 lifetime 3600
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 3600
isakmp policy 30 authentication pre-share
isakmp policy 30 encryption aes-192
isakmp policy 30 hash md5
isakmp policy 30 group 2
isakmp policy 30 lifetime 28800
isakmp nat-traversal  20
isakmp reload-wait

and the acl
access-list ny-vpn-acl extended permit ip 10.1.0.0 255.255.0.0 10.18.15.0 
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.18.0.0 255.255.254.0 10.18.15.0 
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.14.0.0 255.254.0.0 10.18.15.0 
255.255.255.192
access-list ny-vpn-acl extended permit ip 157.254.0.0 255.255.0.0 10.18.15.0 
255.255.255.192
access-list ny-vpn-acl extended permit ip 141.11.0.0 255.255.0.0 10.18.15.0 
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.11.0.0 255.255.0.0 10.18.15.0 
255.255.255.192

TUNNEL GROUP

tunnel-group 208.37.161.98 type ipsec-l2l
tunnel-group 208.37.161.98 general-attributes
 tunnel-group 208.37.161.98 ipsec-attributes
 pre-shared-key *
 peer-id-validate nocheck

PIX

CRYPTO MAP and ISAKMP

crypto ipsec transform-set set1 esp-aes-192 esp-md5-hmac
crypto map map1 10 ipsec-isakmp
crypto map map1 10 match address vpn-1
crypto map map1 10 set peer vpnc
crypto map map1 10 set transform-set set1
crypto map map1 interface outside
isakmp enable outside
isakmp key *
 address vpnc netmask 255.255.255.255
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption aes
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 28800

ACL
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0 255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0 
255.255.240.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0 255.254.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0 
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0 
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0 255.255.0.0

)note on the ASA I use individual /24's and shortened the ACL for ease of 
reasing.  I do this to exclued 10.18.14.0/24 from the tunnels since that 
houses the ASA's inside interface and client access)

Any pointers would be appreciated.

Thanks
Scott

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From tomas at soitron.com  Wed Sep  2 11:07:15 2009
From: tomas at soitron.com (Daniska, Tomas)
Date: Wed, 2 Sep 2009 17:07:15 +0200
Subject: [c-nsp] SXI, TACACS+ in VRF
In-Reply-To: <8D68760F464FFD40A01BF2FB374E4A2801CC1CFC5553@SRVEXC02.aas.its.nja.dk>
References: <6B43981C32F8464CB24CEE209DA32BD302517107@kenya.tronet.as>
	<8D68760F464FFD40A01BF2FB374E4A2801CC1CFC5553@SRVEXC02.aas.its.nja.dk>
Message-ID: <6B43981C32F8464CB24CEE209DA32BD302517190@kenya.tronet.as>

I've managed to work it around in lab by creating a leaked route to the
TAC+ server in the GRT via the management interface. Funny enough, the
switch does not mind sending its packets out GRT and receiving via VRF.
I'll request a ddts tomorrow.

--

deejay


> -----Original Message-----
> From: Arne Larsen / Region Nordjylland [mailto:arla at rn.dk]
> Sent: Wednesday, September 02, 2009 4:05 PM
> To: Daniska, Tomas; cisco-nsp at puck.nether.net
> Subject: SV: SXI, TACACS+ in VRF
> 
> I've got a similar problem with Nexus 5000.
> 
> /Arne
> 
> ________________________________________
> Fra: cisco-nsp-bounces at puck.nether.net [cisco-nsp-
> bounces at puck.nether.net] P&#229; vegne af Daniska, Tomas
> [tomas at soitron.com]
> Sendt: 2. september 2009 14:20
> Til: cisco-nsp at puck.nether.net
> Emne: [c-nsp] SXI, TACACS+ in VRF
> 
> Hi,
> 
> anyone using TACACS+ authentication from VRF in SXI successfully? We
> have login authentication/authorization working, but for enable
> authentication the box somehow fails to connect to the TACACS+ server.
> 
> !
> aaa group server tacacs+ XXX_tacacs
>  server-private x.x.29.142 key ...
>  ip vrf forwarding mgmt
>  ip tacacs source-interface Loopback1
> !
> aaa authentication login XXX group XXX_tacacs local
> aaa authentication enable default group XXX_tacacs enable
> ...
> !
> 
> ...
> Aug 28 17:00:37.285: AAA/AUTHOR: auth_need : user= 'user' ruser=
> 'BA_MN1_CO'rem_addr= 'x.x.251.101' priv= 0 list= '' AUTHOR-TYPE=
> 'command'
> Aug 28 17:00:37.285: AAA: parse name=tty2 idb type=-1 tty=-1
> Aug 28 17:00:37.285: AAA: name=tty2 flags=0x11 type=5 shelf=0 slot=0
> adapter=0 port=2 channel=0
> Aug 28 17:00:37.285: AAA/MEMORY: create_user (0xF7E8CF8) user='user'
> ruser='NULL' ds0=0 port='tty2' rem_addr='x.x.251.101'
authen_type=ASCII
> service=ENABLE priv=15 initial_task_id='0', vrf= (id=0)
> Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): port='tty2'
> list='XXX' action=LOGIN service=ENABLE
> Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): using "default"
> list
> Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): Method=XXX_tacacs
> (tacacs+)
> Aug 28 17:00:37.285: TAC+: send AUTHEN/START packet ver=192 id=-
> 16528696
> Aug 28 17:00:37.285: TAC+: Opening TCP/IP to x.x.29.142/49 timeout=5
> Aug 28 17:00:37.289: TAC+: TCP/IP open to x.x.29.142/49 failed --
> Destination unreachable; gateway or host down
> Aug 28 17:00:37.289: AAA/AUTHEN (4278438600): status = ERROR
> Aug 28 17:00:37.289: AAA/AUTHEN/START (4278438600): Method=ENABLE
> Aug 28 17:00:37.289: AAA/AUTHEN (4278438600): status = GETPASS
> Aug 28 17:00:45.021: AAA/AUTHEN/CONT (4278438600): continue_login
> (user='(undef)')
> Aug 28 17:00:45.021: AAA/AUTHEN (4278438600): status = GETPASS
> Aug 28 17:00:45.021: AAA/AUTHEN/CONT (4278438600): Method=ENABLE
> Aug 28 17:00:45.025: AAA/AUTHEN (4278438600): password incorrect
> Aug 28 17:00:45.025: AAA/AUTHEN (4278438600): status = FAIL
> 
> 
> thx
> 
> --
> 
> deejay
> 
> 
> 
> 
> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 4388
> (20090902) __________
> 
> Tuto spravu preveril ESET NOD32 Antivirus.
> 
> http://www.eset.sk
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 
> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 4389
> (20090902) __________
> 
> Tuto spravu preveril ESET NOD32 Antivirus.
> 
> http://www.eset.sk
> 
 

__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4389
(20090902) __________

Tuto spravu preveril ESET NOD32 Antivirus.

http://www.eset.sk
 

From mulitskiy at acedsl.com  Wed Sep  2 11:08:24 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Wed, 2 Sep 2009 11:08:24 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <20090902142559.M48697@fast-serv.com>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<200909012321.24055.mulitskiy@acedsl.com>
	<20090902142559.M48697@fast-serv.com>
Message-ID: <200909021108.25062.mulitskiy@acedsl.com>

What about the fact that most (if not all) power supplies have independent sucking fan
and that power supply air flow is separate from the system board flow.

Plus all system board I saw are covered with some insulating coating. 
I've never pulled apart a modern power supply. I'd expect them to have something like that too, but who knows?
Plus since PSU is the only part that's dealing with high voltages I expect it to be more sensitive
to momentary shorts. Am I wrong?

I'm expecting report for provider ordered unintrusive power monitoring. 
I'm almost positive they won't find anything, though. 
I'm still looking for advice on independent power analysis source in New York, NY if anyone has this kind of experience.
Thanks,

Michael

On Wednesday 02 September 2009 10:29:07 am Randy McAnally wrote:
> Plain old dust wouldn't be so picky...it has to be ingested past the system
> board before it hits the power supply in most cases.  System boards are WAY
> more sensitive to this kind of thing.
> 
> The fact you have ONLY PSU's failing still makes me think you have power issues.
> 
> --
> Randy
> www.FastServ.com
> 
> ---------- Original Message -----------
> From: Michael Ulitskiy <mulitskiy at acedsl.com>
> To: "Randy McAnally" <rsm at fast-serv.com>
> Cc: "Scott Granados" <gsgranados at comcast.net>, "Seth Mattinen"
> <sethm at rollernet.us>, cisco-nsp at puck.nether.net
> Sent: Tue, 1 Sep 2009 23:21:23 -0400
> Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> 
> > This is my main suspect now. They are doing work in the facility. 
> > Not heavy construction, but they do install cages and cabinets for 
> > new tenants and they're definitely using tools that  produce metal dust.
> > My theory is that because of we've been the 1st customer who moved 
> > into that facility we've been collecting that metal dust for longest 
> > and so we're having a lot of problems with our equipment. To my 
> > knowledge none of our neighbors are having the same problem, but 
> > none of them have been in the place long enough. So the question 
> > remains: is there any way to fight it/protect from it except from 
> > going through the huge-huge-huge headache of undertaking another move?
> > 
> > Michael
> > 
> > On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote:
> > > He mentioned he was one of the first customers in the colo so
> > > this might be a possibility
> > > 
> > > --
> > > Randy
> > > 
> > > ---------- Original Message -----------
> > > From: "Scott Granados" <gsgranados at comcast.net>
> > > To: "Seth Mattinen" <sethm at rollernet.us>, "Michael Ulitskiy"
> > > <mulitskiy at acedsl.com>
> > > Cc: cisco-nsp at puck.nether.net
> > > Sent: Tue, 1 Sep 2009 17:35:34 -0700
> > > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> > > 
> > > > Also make sure that the provider isn't doing work in the facility. 
> > > >  I'll never forget going to an L3 datacenter and arriving to find 
> > > > workmen in the overhead grinding away and dropping dust and who 
> > > > knows what else in to all the racks below including a rack of Netra 
> > > > T1's that promptly sucked in the dust and kicked out power 
> > > > supplies.;)  It was definitely metal shavings because they were 
> > > > using a grinding type tool up in  the over head frames.
> > > > 
> > > 
> > >
> ------- End of Original Message -------
> 
> 



From A.L.M.Buxey at lboro.ac.uk  Wed Sep  2 10:36:47 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Wed, 2 Sep 2009 15:36:47 +0100
Subject: [c-nsp] do i *need* DFCs on the 6500?
In-Reply-To: <alpine.DEB.1.10.0909021400050.20521@uplift.swm.pp.se>
References: <20090902111616.GA6588@lboro.ac.uk>
	<alpine.DEB.1.10.0909021400050.20521@uplift.swm.pp.se>
Message-ID: <20090902143647.GC7276@lboro.ac.uk>

Hi,

> I'd say that if you're not hitting over 10MPPS on the CFC, you don't  
> really need DFC.

is this a figure that can be quoted from somewhere? it seems a very useful pointer -
I can easily graph this value (i hope!) via SNMP and therefore can see if/when
we need the kit :-)

CoPP pointer was very useful too - and I'm interested in best practice policers
:-)


alan

From swmike at swm.pp.se  Wed Sep  2 10:41:43 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 2 Sep 2009 16:41:43 +0200 (CEST)
Subject: [c-nsp] do i *need* DFCs on the 6500?
In-Reply-To: <20090902143647.GC7276@lboro.ac.uk>
References: <20090902111616.GA6588@lboro.ac.uk>
	<alpine.DEB.1.10.0909021400050.20521@uplift.swm.pp.se>
	<20090902143647.GC7276@lboro.ac.uk>
Message-ID: <alpine.DEB.1.10.0909021640230.20521@uplift.swm.pp.se>

On Wed, 2 Sep 2009, Alan Buxey wrote:

> is this a figure that can be quoted from somewhere? it seems a very 
> useful pointer - I can easily graph this value (i hope!) via SNMP and 
> therefore can see if/when we need the kit :-)

10 MPPS comes from "worst case is 15 Mpps (two recycles in the 30Mpps CFC) 
and upgrade before it gets even close to that".

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se

From rsm at fast-serv.com  Wed Sep  2 10:29:07 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Wed, 2 Sep 2009 10:29:07 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <200909012321.24055.mulitskiy@acedsl.com>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<002b01ca2b65$4eda48a0$0202fea9@am.thmulti.com>
	<20090902004658.M47175@fast-serv.com>
	<200909012321.24055.mulitskiy@acedsl.com>
Message-ID: <20090902142559.M48697@fast-serv.com>

Plain old dust wouldn't be so picky...it has to be ingested past the system
board before it hits the power supply in most cases.  System boards are WAY
more sensitive to this kind of thing.

The fact you have ONLY PSU's failing still makes me think you have power issues.

--
Randy
www.FastServ.com

---------- Original Message -----------
From: Michael Ulitskiy <mulitskiy at acedsl.com>
To: "Randy McAnally" <rsm at fast-serv.com>
Cc: "Scott Granados" <gsgranados at comcast.net>, "Seth Mattinen"
<sethm at rollernet.us>, cisco-nsp at puck.nether.net
Sent: Tue, 1 Sep 2009 23:21:23 -0400
Subject: Re: [c-nsp] Multiple power supply failures. Advise needed

> This is my main suspect now. They are doing work in the facility. 
> Not heavy construction, but they do install cages and cabinets for 
> new tenants and they're definitely using tools that  produce metal dust.
> My theory is that because of we've been the 1st customer who moved 
> into that facility we've been collecting that metal dust for longest 
> and so we're having a lot of problems with our equipment. To my 
> knowledge none of our neighbors are having the same problem, but 
> none of them have been in the place long enough. So the question 
> remains: is there any way to fight it/protect from it except from 
> going through the huge-huge-huge headache of undertaking another move?
> 
> Michael
> 
> On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote:
> > He mentioned he was one of the first customers in the colo so
> > this might be a possibility
> > 
> > --
> > Randy
> > 
> > ---------- Original Message -----------
> > From: "Scott Granados" <gsgranados at comcast.net>
> > To: "Seth Mattinen" <sethm at rollernet.us>, "Michael Ulitskiy"
> > <mulitskiy at acedsl.com>
> > Cc: cisco-nsp at puck.nether.net
> > Sent: Tue, 1 Sep 2009 17:35:34 -0700
> > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> > 
> > > Also make sure that the provider isn't doing work in the facility. 
> > >  I'll never forget going to an L3 datacenter and arriving to find 
> > > workmen in the overhead grinding away and dropping dust and who 
> > > knows what else in to all the racks below including a rack of Netra 
> > > T1's that promptly sucked in the dust and kicked out power 
> > > supplies.;)  It was definitely metal shavings because they were 
> > > using a grinding type tool up in  the over head frames.
> > > 
> > 
> >
------- End of Original Message -------


From p.mayers at imperial.ac.uk  Wed Sep  2 11:41:56 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Wed, 02 Sep 2009 16:41:56 +0100
Subject: [c-nsp] parser config cache interface - stable/safe?
Message-ID: <4A9E9244.1020002@imperial.ac.uk>

All,

Is anyone running this? Is it stable/safe? How well does it interact 
with other features e.g. if I "scp fragment admin at router:running-config" 
will it "know" that the interface cache in the fragment config is expired?

Platform of interest is 6500/sup720 running 12.2(33)SXI

From rsm at fast-serv.com  Wed Sep  2 11:49:59 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Wed, 2 Sep 2009 11:49:59 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <200909021108.25062.mulitskiy@acedsl.com>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<200909012321.24055.mulitskiy@acedsl.com>
	<20090902142559.M48697@fast-serv.com>
	<200909021108.25062.mulitskiy@acedsl.com>
Message-ID: <20090902154448.M12644@fast-serv.com>

You mentioned a couple servers failed -- most if not all servers power
supplies blow outward, sucking air from inside the chassis.  Many Cisco
devices work this way also.  I have rarely seen a power supply that sucks air
in directly from the outside of the chassis.

Given the above, much of the dust would settle on the system board.  The
extremely high tolerances of a typical system board far outweigh those of a
power supply, thus I would expect system instability before the power supply
failed.

My bet is still on power spikes/dips.

--
Randy
www.FastServ.com

---------- Original Message -----------
From: Michael Ulitskiy <mulitskiy at acedsl.com>
To: "Randy McAnally" <rsm at fast-serv.com>
Cc: cisco-nsp at puck.nether.net
Sent: Wed, 2 Sep 2009 11:08:24 -0400
Subject: Re: [c-nsp] Multiple power supply failures. Advise needed

> What about the fact that most (if not all) power supplies have 
> independent sucking fan and that power supply air flow is separate 
> from the system board flow.
> 
> Plus all system board I saw are covered with some insulating 
> coating. I've never pulled apart a modern power supply. I'd expect 
> them to have something like that too, but who knows? Plus since PSU 
> is the only part that's dealing with high voltages I expect it to be 
> more sensitive to momentary shorts. Am I wrong?
> 
> I'm expecting report for provider ordered unintrusive power 
> monitoring. I'm almost positive they won't find anything, though. 
> I'm still looking for advice on independent power analysis source in 
> New York, NY if anyone has this kind of experience. Thanks,
> 
> Michael
> 
> On Wednesday 02 September 2009 10:29:07 am Randy McAnally wrote:
> > Plain old dust wouldn't be so picky...it has to be ingested past the system
> > board before it hits the power supply in most cases.  System boards are WAY
> > more sensitive to this kind of thing.
> > 
> > The fact you have ONLY PSU's failing still makes me think you have power
issues.
> > 
> > --
> > Randy
> > www.FastServ.com
> > 
> > ---------- Original Message -----------
> > From: Michael Ulitskiy <mulitskiy at acedsl.com>
> > To: "Randy McAnally" <rsm at fast-serv.com>
> > Cc: "Scott Granados" <gsgranados at comcast.net>, "Seth Mattinen"
> > <sethm at rollernet.us>, cisco-nsp at puck.nether.net
> > Sent: Tue, 1 Sep 2009 23:21:23 -0400
> > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> > 
> > > This is my main suspect now. They are doing work in the facility. 
> > > Not heavy construction, but they do install cages and cabinets for 
> > > new tenants and they're definitely using tools that  produce metal dust.
> > > My theory is that because of we've been the 1st customer who moved 
> > > into that facility we've been collecting that metal dust for longest 
> > > and so we're having a lot of problems with our equipment. To my 
> > > knowledge none of our neighbors are having the same problem, but 
> > > none of them have been in the place long enough. So the question 
> > > remains: is there any way to fight it/protect from it except from 
> > > going through the huge-huge-huge headache of undertaking another move?
> > > 
> > > Michael
> > > 
> > > On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote:
> > > > He mentioned he was one of the first customers in the colo so
> > > > this might be a possibility
> > > > 
> > > > --
> > > > Randy
> > > > 
> > > > ---------- Original Message -----------
> > > > From: "Scott Granados" <gsgranados at comcast.net>
> > > > To: "Seth Mattinen" <sethm at rollernet.us>, "Michael Ulitskiy"
> > > > <mulitskiy at acedsl.com>
> > > > Cc: cisco-nsp at puck.nether.net
> > > > Sent: Tue, 1 Sep 2009 17:35:34 -0700
> > > > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> > > > 
> > > > > Also make sure that the provider isn't doing work in the facility. 
> > > > >  I'll never forget going to an L3 datacenter and arriving to find 
> > > > > workmen in the overhead grinding away and dropping dust and who 
> > > > > knows what else in to all the racks below including a rack of Netra 
> > > > > T1's that promptly sucked in the dust and kicked out power 
> > > > > supplies.;)  It was definitely metal shavings because they were 
> > > > > using a grinding type tool up in  the over head frames.
> > > > > 
> > > > 
> > > >
> > ------- End of Original Message -------
> > 
> >
------- End of Original Message -------


From gert at greenie.muc.de  Wed Sep  2 10:04:38 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 2 Sep 2009 16:04:38 +0200
Subject: [c-nsp] do i *need* DFCs on the 6500?
In-Reply-To: <4A9E6786.5010901@justinshore.com>
References: <20090902111616.GA6588@lboro.ac.uk>
	<4A9E6786.5010901@justinshore.com>
Message-ID: <20090902140438.GB117@greenie.muc.de>

Hi,

On Wed, Sep 02, 2009 at 07:39:34AM -0500, Justin Shore wrote:
> You eluded to one of my strongest selling points on DFCs though I don't 
> think you made that particular connection yet.  DFCs offload QoS to the 
> LC as you said.  That also means that CoPP is also handled in hardware 
> if you have DFCs in place since it requires MLS QoS on that platform. 
> Ie, if your 6500/7600 is going to be publicly-accessible on the Internet 
> in any capacity and you want it to be able to use CoPP to withstand a 
> targeted DoS attack then DFCs are not optional, they're critical.

Why?  Wouldn't the Sup PFC handle "CoPP-in-hardware" if you have no DFCs?

(Assuming that the total incoming packet volume is still inside the 
bounds that the PFC can handle)

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090902/e8c5b323/attachment.bin>

From arla at rn.dk  Wed Sep  2 10:05:09 2009
From: arla at rn.dk (Arne Larsen / Region Nordjylland)
Date: Wed, 2 Sep 2009 16:05:09 +0200
Subject: [c-nsp] SXI, TACACS+ in VRF
In-Reply-To: <6B43981C32F8464CB24CEE209DA32BD302517107@kenya.tronet.as>
References: <6B43981C32F8464CB24CEE209DA32BD302517107@kenya.tronet.as>
Message-ID: <8D68760F464FFD40A01BF2FB374E4A2801CC1CFC5553@SRVEXC02.aas.its.nja.dk>

I?ve got a similar problem with Nexus 5000.

/Arne

________________________________________
Fra: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net] P&#229; vegne af Daniska, Tomas [tomas at soitron.com]
Sendt: 2. september 2009 14:20
Til: cisco-nsp at puck.nether.net
Emne: [c-nsp] SXI, TACACS+ in VRF

Hi,

anyone using TACACS+ authentication from VRF in SXI successfully? We
have login authentication/authorization working, but for enable
authentication the box somehow fails to connect to the TACACS+ server.

!
aaa group server tacacs+ XXX_tacacs
 server-private x.x.29.142 key ...
 ip vrf forwarding mgmt
 ip tacacs source-interface Loopback1
!
aaa authentication login XXX group XXX_tacacs local
aaa authentication enable default group XXX_tacacs enable
...
!

...
Aug 28 17:00:37.285: AAA/AUTHOR: auth_need : user= 'user' ruser=
'BA_MN1_CO'rem_addr= 'x.x.251.101' priv= 0 list= '' AUTHOR-TYPE=
'command'
Aug 28 17:00:37.285: AAA: parse name=tty2 idb type=-1 tty=-1
Aug 28 17:00:37.285: AAA: name=tty2 flags=0x11 type=5 shelf=0 slot=0
adapter=0 port=2 channel=0
Aug 28 17:00:37.285: AAA/MEMORY: create_user (0xF7E8CF8) user='user'
ruser='NULL' ds0=0 port='tty2' rem_addr='x.x.251.101' authen_type=ASCII
service=ENABLE priv=15 initial_task_id='0', vrf= (id=0)
Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): port='tty2'
list='XXX' action=LOGIN service=ENABLE
Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): using "default" list
Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): Method=XXX_tacacs
(tacacs+)
Aug 28 17:00:37.285: TAC+: send AUTHEN/START packet ver=192 id=-16528696
Aug 28 17:00:37.285: TAC+: Opening TCP/IP to x.x.29.142/49 timeout=5
Aug 28 17:00:37.289: TAC+: TCP/IP open to x.x.29.142/49 failed --
Destination unreachable; gateway or host down
Aug 28 17:00:37.289: AAA/AUTHEN (4278438600): status = ERROR
Aug 28 17:00:37.289: AAA/AUTHEN/START (4278438600): Method=ENABLE
Aug 28 17:00:37.289: AAA/AUTHEN (4278438600): status = GETPASS
Aug 28 17:00:45.021: AAA/AUTHEN/CONT (4278438600): continue_login
(user='(undef)')
Aug 28 17:00:45.021: AAA/AUTHEN (4278438600): status = GETPASS
Aug 28 17:00:45.021: AAA/AUTHEN/CONT (4278438600): Method=ENABLE
Aug 28 17:00:45.025: AAA/AUTHEN (4278438600): password incorrect
Aug 28 17:00:45.025: AAA/AUTHEN (4278438600): status = FAIL


thx

--

deejay




__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4388
(20090902) __________

Tuto spravu preveril ESET NOD32 Antivirus.

http://www.eset.sk

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From koszik at atw.hu  Wed Sep  2 08:57:20 2009
From: koszik at atw.hu (Matyas Koszik)
Date: Wed, 2 Sep 2009 14:57:20 +0200 (CEST)
Subject: [c-nsp] do i *need* DFCs on the 6500?
In-Reply-To: <4A9E6786.5010901@justinshore.com>
Message-ID: <Pine.LNX.4.44.0909021454310.24431-100000@hq>


The PFC is capable of the same things as a DFC, just in a centralized
manner. So, for example, CoPP works just fine in hardware with a PFC - you
don't NEED to offload the QoS to the LCs. You need a DFC only if some
resources are close to exhaustion (like pps rates supported by centralized
forwarding, netflow entries, QoS entries and so on).



On Wed, 2 Sep 2009, Justin Shore wrote:

> You eluded to one of my strongest selling points on DFCs though I don't
> think you made that particular connection yet.  DFCs offload QoS to the
> LC as you said.  That also means that CoPP is also handled in hardware
> if you have DFCs in place since it requires MLS QoS on that platform.
> Ie, if your 6500/7600 is going to be publicly-accessible on the Internet
> in any capacity and you want it to be able to use CoPP to withstand a
> targeted DoS attack then DFCs are not optional, they're critical.
>
> The others on the list can probably give you much more in-depth views on
> the other aspects of the card but I found CoPP to be a big enough
> selling point.  It wouldn't be good is a simple little DoS attack took
> down my core 7600s.
>
> Justin
>
>
> Alan Buxey wrote:
> > hi,
> >
> > okay, from the background of I know what the DFC is and how it
> > operates etc... i know I want them - however, I need to justify
> > the upgrade/part cost to sort out a couple of 6500's.  in some of
> > our 6500's, the 10G blades have DFCs already...but several 6724's dont
> > (they just have CFC). ...as i said, I want them, but need to get
> > some management/funding buy-in - and they dont want the 'what it
> > does' information - they want some hard and fast facts that Cisco dont
> > sem to want to tell me ..... so, the question is
> >
> > 1) is there any way of showing the sup720 strain/utilisation...particularly
> > is there a way of showing DFC usage on the blades where we have them?
> >
> > 2) it offloads IPv6 and QoS - we're into both of those (and more so over the
> > next year) - any particular insights into QoS performance/issues without
> > DFC ? any throughput figures for IPv6 ?
> >
> > (i know that with CFC we're limited to the backplane (32mpps?) and we get ~ 48mpps
> > per blade with DFC)
> >
> > ...or could it be that DFC's are only really useful to a particular deployment
> > and I just *think* i need them?  ;-)
> >
> > alan
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


From Peter.George at lumison.net  Wed Sep  2 12:09:02 2009
From: Peter.George at lumison.net (Peter George)
Date: Wed, 2 Sep 2009 17:09:02 +0100
Subject: [c-nsp] Monitoring Techniques ahead of mls rate-limiting
Message-ID: <B5F945E48C137C49A98BC86DD35939C0156B867FE7@nbg01-exch-01.entlstaff.domain.lumison.net>

Hello,

I want to monitor ipv4 multicast and layer2 pdu counters on a Catalyst 6509 Sup32 running 12.2(17r)SX3, in order to set sensible thresholds for the following special case hardware based rate-limiters;

# mls rate-limit multicast ipv4 connected  (Pkts/sec)
# mls rate-limit layer 2 pdu  (Pkts/sec)

I also want to monitor ARP hitting MSFC ahead of applying QoS as follows;

# mls qos protocol arp police (Bits/sec)

Can anyone give me any pointers as to how I can access the specific counters that the rate-limiter and policer threshold will be measured against before dropping packets/bits?

TIA

Regards,

P
--
Peter George
Lumison
t: 0845 1199 900
d: 0131 514 4022

P.S. Lumison have changed the way businesses communicate forever http://www.unified-communications.net/


________________________________
--

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender. Any
offers or quotation of service are subject to formal specification.
Errors and omissions excepted. Please note that any views or opinions
presented in this email are solely those of the author and do not
necessarily represent those of Lumison.
Finally, the recipient should check this email and any attachments for the
presence of viruses. Lumison accept no liability for any
damage caused by any virus transmitted by this email.

From gsgranados at comcast.net  Wed Sep  2 12:12:33 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Wed, 2 Sep 2009 09:12:33 -0700
Subject: [c-nsp] Multiple power supply failures. Advise needed
References: <200908141604.42069.mulitskiy@acedsl.com><200909012321.24055.mulitskiy@acedsl.com><20090902142559.M48697@fast-serv.com>
	<200909021108.25062.mulitskiy@acedsl.com>
Message-ID: <002101ca2be8$3491d520$2208120a@am.thmulti.com>

You're correct, depending on the hardware you're using your supplies could 
be sucking fibers right n to their inner workings.  I don't recall if you 
mentioned so sorry if this is covering old ground but is it only Cisco gear 
you're having issues with or is it random across platforms / hardware types?

----- Original Message ----- 
From: "Michael Ulitskiy" <mulitskiy at acedsl.com>
To: "Randy McAnally" <rsm at fast-serv.com>
Cc: <cisco-nsp at puck.nether.net>
Sent: Wednesday, September 02, 2009 8:08 AM
Subject: Re: [c-nsp] Multiple power supply failures. Advise needed


> What about the fact that most (if not all) power supplies have independent 
> sucking fan
> and that power supply air flow is separate from the system board flow.
>
> Plus all system board I saw are covered with some insulating coating.
> I've never pulled apart a modern power supply. I'd expect them to have 
> something like that too, but who knows?
> Plus since PSU is the only part that's dealing with high voltages I expect 
> it to be more sensitive
> to momentary shorts. Am I wrong?
>
> I'm expecting report for provider ordered unintrusive power monitoring.
> I'm almost positive they won't find anything, though.
> I'm still looking for advice on independent power analysis source in New 
> York, NY if anyone has this kind of experience.
> Thanks,
>
> Michael
>
> On Wednesday 02 September 2009 10:29:07 am Randy McAnally wrote:
>> Plain old dust wouldn't be so picky...it has to be ingested past the 
>> system
>> board before it hits the power supply in most cases.  System boards are 
>> WAY
>> more sensitive to this kind of thing.
>>
>> The fact you have ONLY PSU's failing still makes me think you have power 
>> issues.
>>
>> --
>> Randy
>> www.FastServ.com
>>
>> ---------- Original Message -----------
>> From: Michael Ulitskiy <mulitskiy at acedsl.com>
>> To: "Randy McAnally" <rsm at fast-serv.com>
>> Cc: "Scott Granados" <gsgranados at comcast.net>, "Seth Mattinen"
>> <sethm at rollernet.us>, cisco-nsp at puck.nether.net
>> Sent: Tue, 1 Sep 2009 23:21:23 -0400
>> Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
>>
>> > This is my main suspect now. They are doing work in the facility.
>> > Not heavy construction, but they do install cages and cabinets for
>> > new tenants and they're definitely using tools that  produce metal 
>> > dust.
>> > My theory is that because of we've been the 1st customer who moved
>> > into that facility we've been collecting that metal dust for longest
>> > and so we're having a lot of problems with our equipment. To my
>> > knowledge none of our neighbors are having the same problem, but
>> > none of them have been in the place long enough. So the question
>> > remains: is there any way to fight it/protect from it except from
>> > going through the huge-huge-huge headache of undertaking another move?
>> >
>> > Michael
>> >
>> > On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote:
>> > > He mentioned he was one of the first customers in the colo so
>> > > this might be a possibility
>> > >
>> > > --
>> > > Randy
>> > >
>> > > ---------- Original Message -----------
>> > > From: "Scott Granados" <gsgranados at comcast.net>
>> > > To: "Seth Mattinen" <sethm at rollernet.us>, "Michael Ulitskiy"
>> > > <mulitskiy at acedsl.com>
>> > > Cc: cisco-nsp at puck.nether.net
>> > > Sent: Tue, 1 Sep 2009 17:35:34 -0700
>> > > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
>> > >
>> > > > Also make sure that the provider isn't doing work in the facility.
>> > > >  I'll never forget going to an L3 datacenter and arriving to find
>> > > > workmen in the overhead grinding away and dropping dust and who
>> > > > knows what else in to all the racks below including a rack of Netra
>> > > > T1's that promptly sucked in the dust and kicked out power
>> > > > supplies.;)  It was definitely metal shavings because they were
>> > > > using a grinding type tool up in  the over head frames.
>> > > >
>> > >
>> > >
>> ------- End of Original Message -------
>>
>>
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From pdavis at i2k.com  Wed Sep  2 11:31:38 2009
From: pdavis at i2k.com (Philip Davis)
Date: Wed, 02 Sep 2009 11:31:38 -0400
Subject: [c-nsp] NAT Ager CPU Usage
In-Reply-To: <4A9D3F79.6020405@i2k.com>
References: <4A9D3F79.6020405@i2k.com>
Message-ID: <4A9E8FDA.1070405@i2k.com>

Resolution on this:

Changed IOS from 12.4.(19b) to 12.4.(25b) and the NAT Ager Process is 
now well under 1% with a similar number of translations.

Philip Davis wrote:
> Hello,
>
>  I have a 2621XM that is using more CPU on the NAT aging process that 
> I would expect. At this moment that process is sitting around 15% with 
> ~1700 entries in the NAT translation table. In comparison I have other 
> 2621XMs at other sites doing 2500+ NAT translations where the NAT ager 
> process is using <1% of the CPU. At times the NAT ager will use 50+% 
> of the CPU still with relatively few translations. This causes problems.
>  Does anyone have any idea why this may be happening?
>
>  Thanks,
> Phil
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


-- 

Philip Davis
Systems Administrator
I-2000 Inc.
(616) 532-8425
888-234-4254


From gsgranados at comcast.net  Wed Sep  2 12:35:18 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Wed, 2 Sep 2009 09:35:18 -0700
Subject: [c-nsp] Multiple power supply failures. Advise needed
References: <200908141604.42069.mulitskiy@acedsl.com>
	<002b01ca2b65$4eda48a0$0202fea9@am.thmulti.com>
	<20090902004658.M47175@fast-serv.com>
	<200909012321.24055.mulitskiy@acedsl.com>
Message-ID: <00ca01ca2beb$63701840$2208120a@am.thmulti.com>

One other thing you should check.

I'll never forget being the first customer at the 3080 Raymond facility in 
Santa Clara and coming in one day to find my gear down and sitting in about 
2 inches of water.  The cleaning folks were spraying all sorts of fluids and 
cleaning products on the floors and sucking them up again but not realizing 
that fluids pool.;)  Personally, my bet is on some sort of work / 
maintenance the provider is conducting that's being done baddly or with out 
consideration for effects like metal dust or water.


----- Original Message ----- 
From: "Michael Ulitskiy" <mulitskiy at acedsl.com>
To: "Randy McAnally" <rsm at fast-serv.com>
Cc: "Scott Granados" <gsgranados at comcast.net>; "Seth Mattinen" 
<sethm at rollernet.us>; <cisco-nsp at puck.nether.net>
Sent: Tuesday, September 01, 2009 8:21 PM
Subject: Re: [c-nsp] Multiple power supply failures. Advise needed


> This is my main suspect now. They are doing work in the facility.
> Not heavy construction, but they do install cages and cabinets for new 
> tenants and
> they're definitely using tools that  produce metal dust.
> My theory is that because of we've been the 1st customer who moved into 
> that facility
> we've been collecting that metal dust for longest and so we're having a 
> lot of problems
> with our equipment. To my knowledge none of our neighbors are having the 
> same problem,
> but none of them have been in the place long enough.
> So the question remains: is there any way to fight it/protect from it 
> except from going
> through the huge-huge-huge headache of undertaking another move?
>
> Michael
>
> On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote:
>> He mentioned he was one of the first customers in the colo so
>> this might be a possibility
>>
>> --
>> Randy
>>
>> ---------- Original Message -----------
>> From: "Scott Granados" <gsgranados at comcast.net>
>> To: "Seth Mattinen" <sethm at rollernet.us>, "Michael Ulitskiy"
>> <mulitskiy at acedsl.com>
>> Cc: cisco-nsp at puck.nether.net
>> Sent: Tue, 1 Sep 2009 17:35:34 -0700
>> Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
>>
>> > Also make sure that the provider isn't doing work in the facility.
>> >  I'll never forget going to an L3 datacenter and arriving to find
>> > workmen in the overhead grinding away and dropping dust and who
>> > knows what else in to all the racks below including a rack of Netra
>> > T1's that promptly sucked in the dust and kicked out power
>> > supplies.;)  It was definitely metal shavings because they were
>> > using a grinding type tool up in  the over head frames.
>> >
>>
>>
>
> 


From fasterfourier at gmail.com  Wed Sep  2 12:40:30 2009
From: fasterfourier at gmail.com (Robert Johnson)
Date: Wed, 2 Sep 2009 12:40:30 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <200909021108.25062.mulitskiy@acedsl.com>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<200909012321.24055.mulitskiy@acedsl.com>
	<20090902142559.M48697@fast-serv.com>
	<200909021108.25062.mulitskiy@acedsl.com>
Message-ID: <4f84a6f80909020940o1f4db4can81228747440d6534@mail.gmail.com>

Coming from an electrical engineer:
Before doing anything else, you need to get someone out there with a
recording oscilloscope to verify the input power to your equipment. This is
the best way to ensure that you are getting the proper waveform, and that
your power is free from transients and sags. A normal managed UPS will not
be able to pick up infrequent spikes, harmonic distortion, etc. These are
all single phase 120 volt circuits, right?

Grounding is unlikely to be the problem. As previously mentioned, the safety
ground on the equipment power supply bonds the equipment chassis to the
facility ground. This is adequate in a typical data environment that is not
in a high lightning exposure zone. If you were in a telephone CO, a site
with a communications tower, etc., then it would be worth your while to make
sure that each piece of equipment and metal hardware was bonded back to the
MGB. But based on the information you've given here, I don't think this is
relevant to your power supplies blowing up.

I would go ahead and put some double sided tape on the air intakes for your
equipment. After a few days, peel the tape off and take a look at it using a
microscope or magnifying glass and inspect for metal particles.

Robert

On Wed, Sep 2, 2009 at 11:08 AM, Michael Ulitskiy <mulitskiy at acedsl.com>wrote:

> What about the fact that most (if not all) power supplies have independent
> sucking fan
> and that power supply air flow is separate from the system board flow.
>
> Plus all system board I saw are covered with some insulating coating.
> I've never pulled apart a modern power supply. I'd expect them to have
> something like that too, but who knows?
> Plus since PSU is the only part that's dealing with high voltages I expect
> it to be more sensitive
> to momentary shorts. Am I wrong?
>
> I'm expecting report for provider ordered unintrusive power monitoring.
> I'm almost positive they won't find anything, though.
> I'm still looking for advice on independent power analysis source in New
> York, NY if anyone has this kind of experience.
> Thanks,
>
> Michael
>
> On Wednesday 02 September 2009 10:29:07 am Randy McAnally wrote:
> > Plain old dust wouldn't be so picky...it has to be ingested past the
> system
> > board before it hits the power supply in most cases.  System boards are
> WAY
> > more sensitive to this kind of thing.
> >
> > The fact you have ONLY PSU's failing still makes me think you have power
> issues.
> >
> > --
> > Randy
> > www.FastServ.com
> >
> > ---------- Original Message -----------
> > From: Michael Ulitskiy <mulitskiy at acedsl.com>
> > To: "Randy McAnally" <rsm at fast-serv.com>
> > Cc: "Scott Granados" <gsgranados at comcast.net>, "Seth Mattinen"
> > <sethm at rollernet.us>, cisco-nsp at puck.nether.net
> > Sent: Tue, 1 Sep 2009 23:21:23 -0400
> > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> >
> > > This is my main suspect now. They are doing work in the facility.
> > > Not heavy construction, but they do install cages and cabinets for
> > > new tenants and they're definitely using tools that  produce metal
> dust.
> > > My theory is that because of we've been the 1st customer who moved
> > > into that facility we've been collecting that metal dust for longest
> > > and so we're having a lot of problems with our equipment. To my
> > > knowledge none of our neighbors are having the same problem, but
> > > none of them have been in the place long enough. So the question
> > > remains: is there any way to fight it/protect from it except from
> > > going through the huge-huge-huge headache of undertaking another move?
> > >
> > > Michael
> > >
> > > On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote:
> > > > He mentioned he was one of the first customers in the colo so
> > > > this might be a possibility
> > > >
> > > > --
> > > > Randy
> > > >
> > > > ---------- Original Message -----------
> > > > From: "Scott Granados" <gsgranados at comcast.net>
> > > > To: "Seth Mattinen" <sethm at rollernet.us>, "Michael Ulitskiy"
> > > > <mulitskiy at acedsl.com>
> > > > Cc: cisco-nsp at puck.nether.net
> > > > Sent: Tue, 1 Sep 2009 17:35:34 -0700
> > > > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> > > >
> > > > > Also make sure that the provider isn't doing work in the facility.
> > > > >  I'll never forget going to an L3 datacenter and arriving to find
> > > > > workmen in the overhead grinding away and dropping dust and who
> > > > > knows what else in to all the racks below including a rack of Netra
> > > > > T1's that promptly sucked in the dust and kicked out power
> > > > > supplies.;)  It was definitely metal shavings because they were
> > > > > using a grinding type tool up in  the over head frames.
> > > > >
> > > >
> > > >
> > ------- End of Original Message -------
> >
> >
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From gsgranados at comcast.net  Wed Sep  2 12:45:28 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Wed, 2 Sep 2009 09:45:28 -0700
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
References: <000501ca2b64$54ea36c0$0202fea9@am.thmulti.com>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248E269EB4@zy-ex1.zyedge.local>
Message-ID: <00ea01ca2bec$cc3c98c0$2208120a@am.thmulti.com>

Hi, so right now my Pix in the field is pointing at a VPN 3000 so I can't 
take that path down until after hours but I will to capture the debug data.

A show ver on the asa shows device manager V5.0.7

The field pix shows V6.3
I have access to both ends so updating the firmware is definitely an option. 
Any suggested version?

On the ASA side I do not have a no nat statement at all.  I never configured 
NAT because this device isn't beingused for any features other than a VPN 
access device with split tunneling enabled for the clients.
On the NY pix side the nat config and acl are as follows.

global (outside) 1 208.x.x.100-208.x.x.115 netmask 255.255.255.224
global (outside) 1 208.x.x.99 netmask 255.255.255.224
nat (inside) 0 access-list vpn-1
nat (inside) 1 0.0.0.0 0.0.0.0 0 0

access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0 255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0 
255.255.240.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0 255.254.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0 
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0 
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0 255.255.0.0

Thanks
Scott

----- Original Message ----- 
From: "Ryan West" <rwest at zyedge.com>
To: "Scott Granados" <gsgranados at comcast.net>; <cisco-nsp at puck.nether.net>
Sent: Wednesday, September 02, 2009 6:15 AM
Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel


Scott,

Can you provide debugs from the ASA, code versions on both devices and your 
associated no-nat ACLs?

Assuming you have nothing else logging to monitor, you can enable 'logging 
class vpn monitor debug' and throw up a term mon to gather inbound messages 
to the ASA from the PIX side.  You can gather the information on the PIX 
with a debug cry isa 2 and then initiate interesting traffic from the ASA 
using the following, the more valuable information will be on the receiving 
end.  It really doesn't matter which side you enable as the receiver, but I 
try to stay away from pre 7.x code on the PIXes.

packet-tracer input inside icmp 10.1.0.10 8 0 10.18.15.10 detailed

Phase: 10 or 11 should be subtype encrypt.  If it fails the first time, run 
it again, the negotiation process causes the first packet to fail as the 
tunnel is being brought.  This type of traffic will also give you your debug 
information and help you figure out where the failure is.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net 
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Tuesday, September 01, 2009 8:29 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi, I have a Pix out in the field and an ASA5520 that I'm trying to
configure to pass L2L traffic.  I keep getting an error that says
IKEV1 IP=a.b.c.d removing peer from peer table failed, no match
ip=a.b.c.d unable to remove peer table entry

What am I doing wrong?

Here are the important config bits

asa-5520
crypto map
crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac
crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac
crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac
crypto dynamic-map dynmap 10 set transform-set vpn-transform1 vpn-transform2
vpn-transform3
crypto dynamic-map dynmap 10 set reverse-route
crypto map vpn-ra-map 10 match address ny-vpn-acl
crypto map vpn-ra-map 10 set peer ny-fw-outside
crypto map vpn-ra-map 10 set transform-set vpn-transform2
crypto map vpn-ra-map 10 set reverse-route
crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap
crypto map vpn-ra-map interface outside

ISAKMP

isakmp enable outside
isakmp policy 5 authentication pre-share
isakmp policy 5 encryption aes-256
isakmp policy 5 hash sha
isakmp policy 5 group 7
isakmp policy 5 lifetime 3600
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption aes-256
isakmp policy 10 hash sha
isakmp policy 10 group 5
isakmp policy 10 lifetime 3600
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 3600
isakmp policy 30 authentication pre-share
isakmp policy 30 encryption aes-192
isakmp policy 30 hash md5
isakmp policy 30 group 2
isakmp policy 30 lifetime 28800
isakmp nat-traversal  20
isakmp reload-wait

and the acl
access-list ny-vpn-acl extended permit ip 10.1.0.0 255.255.0.0 10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.18.0.0 255.255.254.0 10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.14.0.0 255.254.0.0 10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 157.254.0.0 255.255.0.0 10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 141.11.0.0 255.255.0.0 10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.11.0.0 255.255.0.0 10.18.15.0
255.255.255.192

TUNNEL GROUP

tunnel-group 208.37.161.98 type ipsec-l2l
tunnel-group 208.37.161.98 general-attributes
 tunnel-group 208.37.161.98 ipsec-attributes
 pre-shared-key *
 peer-id-validate nocheck

PIX

CRYPTO MAP and ISAKMP

crypto ipsec transform-set set1 esp-aes-192 esp-md5-hmac
crypto map map1 10 ipsec-isakmp
crypto map map1 10 match address vpn-1
crypto map map1 10 set peer vpnc
crypto map map1 10 set transform-set set1
crypto map map1 interface outside
isakmp enable outside
isakmp key *
 address vpnc netmask 255.255.255.255
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption aes
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 28800

ACL
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0 255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
255.255.240.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0 255.254.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0 255.255.0.0

)note on the ASA I use individual /24's and shortened the ACL for ease of
reasing.  I do this to exclued 10.18.14.0/24 from the tunnels since that
houses the ASA's inside interface and client access)

Any pointers would be appreciated.

Thanks
Scott

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From mulitskiy at acedsl.com  Wed Sep  2 12:47:57 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Wed, 2 Sep 2009 12:47:57 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <20090902154448.M12644@fast-serv.com>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<200909021108.25062.mulitskiy@acedsl.com>
	<20090902154448.M12644@fast-serv.com>
Message-ID: <200909021247.57218.mulitskiy@acedsl.com>

You made me doubt myself and I went ahead and checked the air flow direction in a 
couple of servers I have in the office handy.
I was under impression that all servers power supplies are sucking air, but I was wrong.
Apparently we have servers working both ways. And here I find another clue.
All server PSUs that failed were sucking air. Does it mean that I'm now to expect system 
board problems in those servers with PSUs sucking air from inside the chassis? Oh, come on...
Also I'm not sure about air flow direction in cisco power supplies. I'll check it out on my
next visit to colo.

Michael

On Wednesday 02 September 2009 11:49:59 am Randy McAnally wrote:
> You mentioned a couple servers failed -- most if not all servers power
> supplies blow outward, sucking air from inside the chassis.  Many Cisco
> devices work this way also.  I have rarely seen a power supply that sucks air
> in directly from the outside of the chassis.
> 
> Given the above, much of the dust would settle on the system board.  The
> extremely high tolerances of a typical system board far outweigh those of a
> power supply, thus I would expect system instability before the power supply
> failed.
> 
> My bet is still on power spikes/dips.
> 
> --
> Randy
> www.FastServ.com
> 
> ---------- Original Message -----------
> From: Michael Ulitskiy <mulitskiy at acedsl.com>
> To: "Randy McAnally" <rsm at fast-serv.com>
> Cc: cisco-nsp at puck.nether.net
> Sent: Wed, 2 Sep 2009 11:08:24 -0400
> Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> 
> > What about the fact that most (if not all) power supplies have 
> > independent sucking fan and that power supply air flow is separate 
> > from the system board flow.
> > 
> > Plus all system board I saw are covered with some insulating 
> > coating. I've never pulled apart a modern power supply. I'd expect 
> > them to have something like that too, but who knows? Plus since PSU 
> > is the only part that's dealing with high voltages I expect it to be 
> > more sensitive to momentary shorts. Am I wrong?
> > 
> > I'm expecting report for provider ordered unintrusive power 
> > monitoring. I'm almost positive they won't find anything, though. 
> > I'm still looking for advice on independent power analysis source in 
> > New York, NY if anyone has this kind of experience. Thanks,
> > 
> > Michael
> > 
> > On Wednesday 02 September 2009 10:29:07 am Randy McAnally wrote:
> > > Plain old dust wouldn't be so picky...it has to be ingested past the system
> > > board before it hits the power supply in most cases.  System boards are WAY
> > > more sensitive to this kind of thing.
> > > 
> > > The fact you have ONLY PSU's failing still makes me think you have power
> issues.
> > > 
> > > --
> > > Randy
> > > www.FastServ.com
> > > 
> > > ---------- Original Message -----------
> > > From: Michael Ulitskiy <mulitskiy at acedsl.com>
> > > To: "Randy McAnally" <rsm at fast-serv.com>
> > > Cc: "Scott Granados" <gsgranados at comcast.net>, "Seth Mattinen"
> > > <sethm at rollernet.us>, cisco-nsp at puck.nether.net
> > > Sent: Tue, 1 Sep 2009 23:21:23 -0400
> > > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> > > 
> > > > This is my main suspect now. They are doing work in the facility. 
> > > > Not heavy construction, but they do install cages and cabinets for 
> > > > new tenants and they're definitely using tools that  produce metal dust.
> > > > My theory is that because of we've been the 1st customer who moved 
> > > > into that facility we've been collecting that metal dust for longest 
> > > > and so we're having a lot of problems with our equipment. To my 
> > > > knowledge none of our neighbors are having the same problem, but 
> > > > none of them have been in the place long enough. So the question 
> > > > remains: is there any way to fight it/protect from it except from 
> > > > going through the huge-huge-huge headache of undertaking another move?
> > > > 
> > > > Michael
> > > > 
> > > > On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote:
> > > > > He mentioned he was one of the first customers in the colo so
> > > > > this might be a possibility
> > > > > 
> > > > > --
> > > > > Randy
> > > > > 
> > > > > ---------- Original Message -----------
> > > > > From: "Scott Granados" <gsgranados at comcast.net>
> > > > > To: "Seth Mattinen" <sethm at rollernet.us>, "Michael Ulitskiy"
> > > > > <mulitskiy at acedsl.com>
> > > > > Cc: cisco-nsp at puck.nether.net
> > > > > Sent: Tue, 1 Sep 2009 17:35:34 -0700
> > > > > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> > > > > 
> > > > > > Also make sure that the provider isn't doing work in the facility. 
> > > > > >  I'll never forget going to an L3 datacenter and arriving to find 
> > > > > > workmen in the overhead grinding away and dropping dust and who 
> > > > > > knows what else in to all the racks below including a rack of Netra 
> > > > > > T1's that promptly sucked in the dust and kicked out power 
> > > > > > supplies.;)  It was definitely metal shavings because they were 
> > > > > > using a grinding type tool up in  the over head frames.
> > > > > > 
> > > > > 
> > > > >
> > > ------- End of Original Message -------
> > > 
> > >
> ------- End of Original Message -------
> 
> 



From Steven.Raymond at integratelecom.com  Wed Sep  2 12:49:17 2009
From: Steven.Raymond at integratelecom.com (Raymond, Steven)
Date: Wed, 2 Sep 2009 09:49:17 -0700
Subject: [c-nsp] parser config cache interface - stable/safe?
In-Reply-To: <4A9E9244.1020002@imperial.ac.uk>
References: <4A9E9244.1020002@imperial.ac.uk>
Message-ID: <775A75B5625C6B418FC01477094E0BCC25A1106850@IDCMAILBOX1.ads.integratelecom.com>

> Is anyone running this? Is it stable/safe? How well does it interact
> with other features e.g. if I "scp fragment admin at router:running-config"
> will it "know" that the interface cache in the fragment config is expired?

Running SRA/SRB/SRD, we have seen a few instances (>5) of the "real" running config being out of sync with the output of show run interface.  Problem was easily cleared by removing/reading the parser cache command.

Have not tested the scp results under those circumstances.

The benefit of the config cache is significant.  Loaded chassis without cache sometimes take maybe 30-60 seconds to begin outputting from a show run.


From mulitskiy at acedsl.com  Wed Sep  2 12:55:16 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Wed, 2 Sep 2009 12:55:16 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <002101ca2be8$3491d520$2208120a@am.thmulti.com>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<200909021108.25062.mulitskiy@acedsl.com>
	<002101ca2be8$3491d520$2208120a@am.thmulti.com>
Message-ID: <200909021255.16691.mulitskiy@acedsl.com>

It's different kind of Cisco power supplies (WS-CAC-2500W, WS-CAC-1300W, AS54HPX-AC-RPS)
plus servers power supplies (PWS-0055)

Michael

On Wednesday 02 September 2009 12:12:33 pm you wrote:
> You're correct, depending on the hardware you're using your supplies could 
> be sucking fibers right n to their inner workings.  I don't recall if you 
> mentioned so sorry if this is covering old ground but is it only Cisco gear 
> you're having issues with or is it random across platforms / hardware types?
> 
> ----- Original Message ----- 
> From: "Michael Ulitskiy" <mulitskiy at acedsl.com>
> To: "Randy McAnally" <rsm at fast-serv.com>
> Cc: <cisco-nsp at puck.nether.net>
> Sent: Wednesday, September 02, 2009 8:08 AM
> Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> 
> 
> > What about the fact that most (if not all) power supplies have independent 
> > sucking fan
> > and that power supply air flow is separate from the system board flow.
> >
> > Plus all system board I saw are covered with some insulating coating.
> > I've never pulled apart a modern power supply. I'd expect them to have 
> > something like that too, but who knows?
> > Plus since PSU is the only part that's dealing with high voltages I expect 
> > it to be more sensitive
> > to momentary shorts. Am I wrong?
> >
> > I'm expecting report for provider ordered unintrusive power monitoring.
> > I'm almost positive they won't find anything, though.
> > I'm still looking for advice on independent power analysis source in New 
> > York, NY if anyone has this kind of experience.
> > Thanks,
> >
> > Michael
> >
> > On Wednesday 02 September 2009 10:29:07 am Randy McAnally wrote:
> >> Plain old dust wouldn't be so picky...it has to be ingested past the 
> >> system
> >> board before it hits the power supply in most cases.  System boards are 
> >> WAY
> >> more sensitive to this kind of thing.
> >>
> >> The fact you have ONLY PSU's failing still makes me think you have power 
> >> issues.
> >>
> >> --
> >> Randy
> >> www.FastServ.com
> >>
> >> ---------- Original Message -----------
> >> From: Michael Ulitskiy <mulitskiy at acedsl.com>
> >> To: "Randy McAnally" <rsm at fast-serv.com>
> >> Cc: "Scott Granados" <gsgranados at comcast.net>, "Seth Mattinen"
> >> <sethm at rollernet.us>, cisco-nsp at puck.nether.net
> >> Sent: Tue, 1 Sep 2009 23:21:23 -0400
> >> Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> >>
> >> > This is my main suspect now. They are doing work in the facility.
> >> > Not heavy construction, but they do install cages and cabinets for
> >> > new tenants and they're definitely using tools that  produce metal 
> >> > dust.
> >> > My theory is that because of we've been the 1st customer who moved
> >> > into that facility we've been collecting that metal dust for longest
> >> > and so we're having a lot of problems with our equipment. To my
> >> > knowledge none of our neighbors are having the same problem, but
> >> > none of them have been in the place long enough. So the question
> >> > remains: is there any way to fight it/protect from it except from
> >> > going through the huge-huge-huge headache of undertaking another move?
> >> >
> >> > Michael
> >> >
> >> > On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote:
> >> > > He mentioned he was one of the first customers in the colo so
> >> > > this might be a possibility
> >> > >
> >> > > --
> >> > > Randy
> >> > >
> >> > > ---------- Original Message -----------
> >> > > From: "Scott Granados" <gsgranados at comcast.net>
> >> > > To: "Seth Mattinen" <sethm at rollernet.us>, "Michael Ulitskiy"
> >> > > <mulitskiy at acedsl.com>
> >> > > Cc: cisco-nsp at puck.nether.net
> >> > > Sent: Tue, 1 Sep 2009 17:35:34 -0700
> >> > > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> >> > >
> >> > > > Also make sure that the provider isn't doing work in the facility.
> >> > > >  I'll never forget going to an L3 datacenter and arriving to find
> >> > > > workmen in the overhead grinding away and dropping dust and who
> >> > > > knows what else in to all the racks below including a rack of Netra
> >> > > > T1's that promptly sucked in the dust and kicked out power
> >> > > > supplies.;)  It was definitely metal shavings because they were
> >> > > > using a grinding type tool up in  the over head frames.
> >> > > >
> >> > >
> >> > >
> >> ------- End of Original Message -------
> >>
> >>
> >
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/ 
> 
> 



From rsm at fast-serv.com  Wed Sep  2 12:58:38 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Wed, 2 Sep 2009 12:58:38 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <200909021247.57218.mulitskiy@acedsl.com>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<200909021108.25062.mulitskiy@acedsl.com>
	<20090902154448.M12644@fast-serv.com>
	<200909021247.57218.mulitskiy@acedsl.com>
Message-ID: <20090902165701.M5205@fast-serv.com>

The double sided sticky tape method mentioned should work, assuming there are
still particles in the air.  There is a possibility it came in a short burst
while they were doing work in or near the air plenum.

I would definitely look for particles inside the servers, if you have any you
can take offline temporarily.

--
Randy
www.FastServ.com

---------- Original Message -----------
From: Michael Ulitskiy <mulitskiy at acedsl.com>
To: "Randy McAnally" <rsm at fast-serv.com>
Cc: cisco-nsp at puck.nether.net
Sent: Wed, 2 Sep 2009 12:47:57 -0400
Subject: Re: [c-nsp] Multiple power supply failures. Advise needed

> You made me doubt myself and I went ahead and checked the air flow 
> direction in a couple of servers I have in the office handy. I was 
> under impression that all servers power supplies are sucking air,
>  but I was wrong. Apparently we have servers working both ways. And 
> here I find another clue. All server PSUs that failed were sucking 
> air. Does it mean that I'm now to expect system board problems in 
> those servers with PSUs sucking air from inside the chassis? Oh, 
> come on... Also I'm not sure about air flow direction in cisco power 
> supplies. I'll check it out on my next visit to colo.
> 
> Michael
> 
> On Wednesday 02 September 2009 11:49:59 am Randy McAnally wrote:
> > You mentioned a couple servers failed -- most if not all servers power
> > supplies blow outward, sucking air from inside the chassis.  Many Cisco
> > devices work this way also.  I have rarely seen a power supply that sucks air
> > in directly from the outside of the chassis.
> > 
> > Given the above, much of the dust would settle on the system board.  The
> > extremely high tolerances of a typical system board far outweigh those of a
> > power supply, thus I would expect system instability before the power supply
> > failed.
> > 
> > My bet is still on power spikes/dips.
> > 
> > --
> > Randy
> > www.FastServ.com
> > 
> > ---------- Original Message -----------
> > From: Michael Ulitskiy <mulitskiy at acedsl.com>
> > To: "Randy McAnally" <rsm at fast-serv.com>
> > Cc: cisco-nsp at puck.nether.net
> > Sent: Wed, 2 Sep 2009 11:08:24 -0400
> > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> > 
> > > What about the fact that most (if not all) power supplies have 
> > > independent sucking fan and that power supply air flow is separate 
> > > from the system board flow.
> > > 
> > > Plus all system board I saw are covered with some insulating 
> > > coating. I've never pulled apart a modern power supply. I'd expect 
> > > them to have something like that too, but who knows? Plus since PSU 
> > > is the only part that's dealing with high voltages I expect it to be 
> > > more sensitive to momentary shorts. Am I wrong?
> > > 
> > > I'm expecting report for provider ordered unintrusive power 
> > > monitoring. I'm almost positive they won't find anything, though. 
> > > I'm still looking for advice on independent power analysis source in 
> > > New York, NY if anyone has this kind of experience. Thanks,
> > > 
> > > Michael
> > > 
> > > On Wednesday 02 September 2009 10:29:07 am Randy McAnally wrote:
> > > > Plain old dust wouldn't be so picky...it has to be ingested past the
system
> > > > board before it hits the power supply in most cases.  System boards
are WAY
> > > > more sensitive to this kind of thing.
> > > > 
> > > > The fact you have ONLY PSU's failing still makes me think you have power
> > issues.
> > > > 
> > > > --
> > > > Randy
> > > > www.FastServ.com
> > > > 
> > > > ---------- Original Message -----------
> > > > From: Michael Ulitskiy <mulitskiy at acedsl.com>
> > > > To: "Randy McAnally" <rsm at fast-serv.com>
> > > > Cc: "Scott Granados" <gsgranados at comcast.net>, "Seth Mattinen"
> > > > <sethm at rollernet.us>, cisco-nsp at puck.nether.net
> > > > Sent: Tue, 1 Sep 2009 23:21:23 -0400
> > > > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> > > > 
> > > > > This is my main suspect now. They are doing work in the facility. 
> > > > > Not heavy construction, but they do install cages and cabinets for 
> > > > > new tenants and they're definitely using tools that  produce metal dust.
> > > > > My theory is that because of we've been the 1st customer who moved 
> > > > > into that facility we've been collecting that metal dust for longest 
> > > > > and so we're having a lot of problems with our equipment. To my 
> > > > > knowledge none of our neighbors are having the same problem, but 
> > > > > none of them have been in the place long enough. So the question 
> > > > > remains: is there any way to fight it/protect from it except from 
> > > > > going through the huge-huge-huge headache of undertaking another move?
> > > > > 
> > > > > Michael
> > > > > 
> > > > > On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote:
> > > > > > He mentioned he was one of the first customers in the colo so
> > > > > > this might be a possibility
> > > > > > 
> > > > > > --
> > > > > > Randy
> > > > > > 
> > > > > > ---------- Original Message -----------
> > > > > > From: "Scott Granados" <gsgranados at comcast.net>
> > > > > > To: "Seth Mattinen" <sethm at rollernet.us>, "Michael Ulitskiy"
> > > > > > <mulitskiy at acedsl.com>
> > > > > > Cc: cisco-nsp at puck.nether.net
> > > > > > Sent: Tue, 1 Sep 2009 17:35:34 -0700
> > > > > > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> > > > > > 
> > > > > > > Also make sure that the provider isn't doing work in the facility. 
> > > > > > >  I'll never forget going to an L3 datacenter and arriving to find 
> > > > > > > workmen in the overhead grinding away and dropping dust and who 
> > > > > > > knows what else in to all the racks below including a rack of Netra 
> > > > > > > T1's that promptly sucked in the dust and kicked out power 
> > > > > > > supplies.;)  It was definitely metal shavings because they were 
> > > > > > > using a grinding type tool up in  the over head frames.
> > > > > > > 
> > > > > > 
> > > > > >
> > > > ------- End of Original Message -------
> > > > 
> > > >
> > ------- End of Original Message -------
> > 
> >
------- End of Original Message -------


From copse at xy.org  Wed Sep  2 13:01:20 2009
From: copse at xy.org (Roger Wiklund)
Date: Wed, 2 Sep 2009 19:01:20 +0200
Subject: [c-nsp] MPLS 2 Hub sites with loadsharing,
	same or separate AS numbers?
Message-ID: <c960e2120909021001p6f9c1799m7d19c05844afa7d8@mail.gmail.com>

Hi

I have a question regarding AS numbers, whats the best solution, and
pros/cons with the different setups?

Let say there is an MPLS provider, and one customer has a HUB-site with dual
CPE in the VPN. Each CE router is connected to 2 different PE routers.
Behind each CE router the customer has a Juniper router and are using eBGP
to peer with us.

They want per session loadsharing between the to CPEs. The MPLS provider are
not planning to run iBGP between the CE routers. Only eBGP to the PE.

Now, should these 2 CE routers belong the the same AS number? Let say, 100.
Or should they be in separate? 100, and 200?
You should still be able to loadshare with max-path eibgp 2 on the PEs even
if they are in different AS numbers right? It is only the AS path lengt that
is compared, not the actual number if im not misstaken.

Any pros/cons with the different setups, same AS, different AS.

Thanks!
Roger

From mulitskiy at acedsl.com  Wed Sep  2 13:02:07 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Wed, 2 Sep 2009 13:02:07 -0400
Subject: [c-nsp] Multiple power supply failures. Advise needed
In-Reply-To: <4f84a6f80909020940o1f4db4can81228747440d6534@mail.gmail.com>
References: <200908141604.42069.mulitskiy@acedsl.com>
	<200909021108.25062.mulitskiy@acedsl.com>
	<4f84a6f80909020940o1f4db4can81228747440d6534@mail.gmail.com>
Message-ID: <200909021302.07253.mulitskiy@acedsl.com>

please see inline

On Wednesday 02 September 2009 12:40:30 pm Robert Johnson wrote:
> Coming from an electrical engineer:
> Before doing anything else, you need to get someone out there with a
> recording oscilloscope to verify the input power to your equipment. This is

That's what I have now sitting in my cage. Apparently this is what they call "unintrusive power monitoring".
Can't wait for the result.

> the best way to ensure that you are getting the proper waveform, and that
> your power is free from transients and sags. A normal managed UPS will not
> be able to pick up infrequent spikes, harmonic distortion, etc. These are
> all single phase 120 volt circuits, right?

Correct

> Grounding is unlikely to be the problem. As previously mentioned, the safety
> ground on the equipment power supply bonds the equipment chassis to the
> facility ground. This is adequate in a typical data environment that is not
> in a high lightning exposure zone. If you were in a telephone CO, a site
> with a communications tower, etc., then it would be worth your while to make
> sure that each piece of equipment and metal hardware was bonded back to the
> MGB. But based on the information you've given here, I don't think this is
> relevant to your power supplies blowing up.
> 
> I would go ahead and put some double sided tape on the air intakes for your
> equipment. After a few days, peel the tape off and take a look at it using a
> microscope or magnifying glass and inspect for metal particles.

Yes, I'm going to do something like that, thanks. Also I'm going to open a couple of raised floor tiles
and see how dirty it is over there.

> Robert
> 
> On Wed, Sep 2, 2009 at 11:08 AM, Michael Ulitskiy <mulitskiy at acedsl.com>wrote:
> 
> > What about the fact that most (if not all) power supplies have independent
> > sucking fan
> > and that power supply air flow is separate from the system board flow.
> >
> > Plus all system board I saw are covered with some insulating coating.
> > I've never pulled apart a modern power supply. I'd expect them to have
> > something like that too, but who knows?
> > Plus since PSU is the only part that's dealing with high voltages I expect
> > it to be more sensitive
> > to momentary shorts. Am I wrong?
> >
> > I'm expecting report for provider ordered unintrusive power monitoring.
> > I'm almost positive they won't find anything, though.
> > I'm still looking for advice on independent power analysis source in New
> > York, NY if anyone has this kind of experience.
> > Thanks,
> >
> > Michael
> >
> > On Wednesday 02 September 2009 10:29:07 am Randy McAnally wrote:
> > > Plain old dust wouldn't be so picky...it has to be ingested past the
> > system
> > > board before it hits the power supply in most cases.  System boards are
> > WAY
> > > more sensitive to this kind of thing.
> > >
> > > The fact you have ONLY PSU's failing still makes me think you have power
> > issues.
> > >
> > > --
> > > Randy
> > > www.FastServ.com
> > >
> > > ---------- Original Message -----------
> > > From: Michael Ulitskiy <mulitskiy at acedsl.com>
> > > To: "Randy McAnally" <rsm at fast-serv.com>
> > > Cc: "Scott Granados" <gsgranados at comcast.net>, "Seth Mattinen"
> > > <sethm at rollernet.us>, cisco-nsp at puck.nether.net
> > > Sent: Tue, 1 Sep 2009 23:21:23 -0400
> > > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> > >
> > > > This is my main suspect now. They are doing work in the facility.
> > > > Not heavy construction, but they do install cages and cabinets for
> > > > new tenants and they're definitely using tools that  produce metal
> > dust.
> > > > My theory is that because of we've been the 1st customer who moved
> > > > into that facility we've been collecting that metal dust for longest
> > > > and so we're having a lot of problems with our equipment. To my
> > > > knowledge none of our neighbors are having the same problem, but
> > > > none of them have been in the place long enough. So the question
> > > > remains: is there any way to fight it/protect from it except from
> > > > going through the huge-huge-huge headache of undertaking another move?
> > > >
> > > > Michael
> > > >
> > > > On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote:
> > > > > He mentioned he was one of the first customers in the colo so
> > > > > this might be a possibility
> > > > >
> > > > > --
> > > > > Randy
> > > > >
> > > > > ---------- Original Message -----------
> > > > > From: "Scott Granados" <gsgranados at comcast.net>
> > > > > To: "Seth Mattinen" <sethm at rollernet.us>, "Michael Ulitskiy"
> > > > > <mulitskiy at acedsl.com>
> > > > > Cc: cisco-nsp at puck.nether.net
> > > > > Sent: Tue, 1 Sep 2009 17:35:34 -0700
> > > > > Subject: Re: [c-nsp] Multiple power supply failures. Advise needed
> > > > >
> > > > > > Also make sure that the provider isn't doing work in the facility.
> > > > > >  I'll never forget going to an L3 datacenter and arriving to find
> > > > > > workmen in the overhead grinding away and dropping dust and who
> > > > > > knows what else in to all the racks below including a rack of Netra
> > > > > > T1's that promptly sucked in the dust and kicked out power
> > > > > > supplies.;)  It was definitely metal shavings because they were
> > > > > > using a grinding type tool up in  the over head frames.
> > > > > >
> > > > >
> > > > >
> > > ------- End of Original Message -------
> > >
> > >
> >
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> 



From copse at xy.org  Wed Sep  2 13:04:24 2009
From: copse at xy.org (Roger Wiklund)
Date: Wed, 2 Sep 2009 19:04:24 +0200
Subject: [c-nsp] MPLS 2 Hub sites with loadsharing,
	same or separate AS numbers?
In-Reply-To: <c960e2120909021001p6f9c1799m7d19c05844afa7d8@mail.gmail.com>
References: <c960e2120909021001p6f9c1799m7d19c05844afa7d8@mail.gmail.com>
Message-ID: <c960e2120909021004x671e64b9o24910ea03cccf702@mail.gmail.com>

Sorry, should be: "Each CE router is connected to different PE routers"

And also, I forgot, pros/cons with running iBGP between the CE routers? I
know this is a benefit on the Internet, with two different ISPs, for optimal
routing, but in a MPLS cloud with the same provider I dont see that benefit.

Thanks!
Roger

On Wed, Sep 2, 2009 at 7:01 PM, Roger Wiklund <copse at xy.org> wrote:

> Hi
>
> I have a question regarding AS numbers, whats the best solution, and
> pros/cons with the different setups?
>
> Let say there is an MPLS provider, and one customer has a HUB-site with
> dual CPE in the VPN. Each CE router is connected to 2 different PE routers.
> Behind each CE router the customer has a Juniper router and are using eBGP
> to peer with us.
>
> They want per session loadsharing between the to CPEs. The MPLS provider
> are not planning to run iBGP between the CE routers. Only eBGP to the PE.
>
> Now, should these 2 CE routers belong the the same AS number? Let say, 100.
> Or should they be in separate? 100, and 200?
> You should still be able to loadshare with max-path eibgp 2 on the PEs even
> if they are in different AS numbers right? It is only the AS path lengt that
> is compared, not the actual number if im not misstaken.
>
> Any pros/cons with the different setups, same AS, different AS.
>
> Thanks!
> Roger
>

From malitsky at netabn.com  Wed Sep  2 12:38:36 2009
From: malitsky at netabn.com (Michael Malitsky)
Date: Wed, 2 Sep 2009 11:38:36 -0500
Subject: [c-nsp] Geographically dispersed ASA failover?
Message-ID: <79AF0C3901752A49881FE4CB31F7AA40016ECC39@abn-borg2.NETABN.LOCAL>

Hello,

Does anyone know if the ASA failover feature supports a setup where the
ASAs are in geographically different locations?  Specifically, I have
two data centers about 30 miles apart, connected by a 50Mb metro
ethernet link with latency under 10ms.  

Thanks,
Michael Malitsky



From mksmith at adhost.com  Wed Sep  2 13:33:23 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Wed, 2 Sep 2009 10:33:23 -0700
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
In-Reply-To: <00ea01ca2bec$cc3c98c0$2208120a@am.thmulti.com>
References: <000501ca2b64$54ea36c0$0202fea9@am.thmulti.com><6E21B2BDEF6E714EA0B5BA8D5D0E1401248E269EB4@zy-ex1.zyedge.local>
	<00ea01ca2bec$cc3c98c0$2208120a@am.thmulti.com>
Message-ID: <17838240D9A5544AAA5FF95F8D520316069347A7@ad-exh01.adhost.lan>

Hello Ryan:

Without the no-nat on the ASA side it will try to NAT the traffic before
putting it down the tunnel.  So, you're remove side is looking for the
10. Addresses, but it's going to see traffic coming from the static
outside, NAT'd address.  Thus, the tunnel won't come up because your
proposals don't match.

Mike

--
Michael K. Smith - CISSP, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Wednesday, September 02, 2009 9:45 AM
To: Ryan West; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi, so right now my Pix in the field is pointing at a VPN 3000 so I
can't 
take that path down until after hours but I will to capture the debug
data.

A show ver on the asa shows device manager V5.0.7

The field pix shows V6.3
I have access to both ends so updating the firmware is definitely an
option. 
Any suggested version?

On the ASA side I do not have a no nat statement at all.  I never
configured 
NAT because this device isn't beingused for any features other than a
VPN 
access device with split tunneling enabled for the clients.
On the NY pix side the nat config and acl are as follows.

global (outside) 1 208.x.x.100-208.x.x.115 netmask 255.255.255.224
global (outside) 1 208.x.x.99 netmask 255.255.255.224
nat (inside) 0 access-list vpn-1
nat (inside) 1 0.0.0.0 0.0.0.0 0 0

access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0 
255.255.240.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
255.254.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0 
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0 
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
255.255.0.0

Thanks
Scott

----- Original Message ----- 
From: "Ryan West" <rwest at zyedge.com>
To: "Scott Granados" <gsgranados at comcast.net>;
<cisco-nsp at puck.nether.net>
Sent: Wednesday, September 02, 2009 6:15 AM
Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel


Scott,

Can you provide debugs from the ASA, code versions on both devices and
your 
associated no-nat ACLs?

Assuming you have nothing else logging to monitor, you can enable
'logging 
class vpn monitor debug' and throw up a term mon to gather inbound
messages 
to the ASA from the PIX side.  You can gather the information on the PIX

with a debug cry isa 2 and then initiate interesting traffic from the
ASA 
using the following, the more valuable information will be on the
receiving 
end.  It really doesn't matter which side you enable as the receiver,
but I 
try to stay away from pre 7.x code on the PIXes.

packet-tracer input inside icmp 10.1.0.10 8 0 10.18.15.10 detailed

Phase: 10 or 11 should be subtype encrypt.  If it fails the first time,
run 
it again, the negotiation process causes the first packet to fail as the

tunnel is being brought.  This type of traffic will also give you your
debug 
information and help you figure out where the failure is.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net 
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Tuesday, September 01, 2009 8:29 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi, I have a Pix out in the field and an ASA5520 that I'm trying to
configure to pass L2L traffic.  I keep getting an error that says
IKEV1 IP=a.b.c.d removing peer from peer table failed, no match
ip=a.b.c.d unable to remove peer table entry

What am I doing wrong?

Here are the important config bits

asa-5520
crypto map
crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac
crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac
crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac
crypto dynamic-map dynmap 10 set transform-set vpn-transform1
vpn-transform2
vpn-transform3
crypto dynamic-map dynmap 10 set reverse-route
crypto map vpn-ra-map 10 match address ny-vpn-acl
crypto map vpn-ra-map 10 set peer ny-fw-outside
crypto map vpn-ra-map 10 set transform-set vpn-transform2
crypto map vpn-ra-map 10 set reverse-route
crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap
crypto map vpn-ra-map interface outside

ISAKMP

isakmp enable outside
isakmp policy 5 authentication pre-share
isakmp policy 5 encryption aes-256
isakmp policy 5 hash sha
isakmp policy 5 group 7
isakmp policy 5 lifetime 3600
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption aes-256
isakmp policy 10 hash sha
isakmp policy 10 group 5
isakmp policy 10 lifetime 3600
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 3600
isakmp policy 30 authentication pre-share
isakmp policy 30 encryption aes-192
isakmp policy 30 hash md5
isakmp policy 30 group 2
isakmp policy 30 lifetime 28800
isakmp nat-traversal  20
isakmp reload-wait

and the acl
access-list ny-vpn-acl extended permit ip 10.1.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.18.0.0 255.255.254.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.14.0.0 255.254.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 157.254.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 141.11.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.11.0.0 255.255.0.0
10.18.15.0
255.255.255.192

TUNNEL GROUP

tunnel-group 208.37.161.98 type ipsec-l2l
tunnel-group 208.37.161.98 general-attributes
 tunnel-group 208.37.161.98 ipsec-attributes
 pre-shared-key *
 peer-id-validate nocheck

PIX

CRYPTO MAP and ISAKMP

crypto ipsec transform-set set1 esp-aes-192 esp-md5-hmac
crypto map map1 10 ipsec-isakmp
crypto map map1 10 match address vpn-1
crypto map map1 10 set peer vpnc
crypto map map1 10 set transform-set set1
crypto map map1 interface outside
isakmp enable outside
isakmp key *
 address vpnc netmask 255.255.255.255
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption aes
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 28800

ACL
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
255.255.240.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
255.254.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
255.255.0.0

)note on the ASA I use individual /24's and shortened the ACL for ease
of
reasing.  I do this to exclued 10.18.14.0/24 from the tunnels since that
houses the ASA's inside interface and client access)

Any pointers would be appreciated.

Thanks
Scott

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/ 

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From gsgranados at comcast.net  Wed Sep  2 13:43:35 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Wed, 2 Sep 2009 10:43:35 -0700
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
References: <000501ca2b64$54ea36c0$0202fea9@am.thmulti.com><6E21B2BDEF6E714EA0B5BA8D5D0E1401248E269EB4@zy-ex1.zyedge.local>
	<00ea01ca2bec$cc3c98c0$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347A7@ad-exh01.adhost.lan>
Message-ID: <012501ca2bf4$ec98c550$2208120a@am.thmulti.com>

Hi Mike, to follow up on this, I do have existing clients working now.  For 
the nonat rule would I create a sepperate ACL for each target or would a 
basic acl like I use for the split tunneling do the trick?

either
access-list ny-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.0 
255.255.255.192
or would
access-list nonat standard permit 10.18.0.0 255.255.255.0

I have several different targets so how would one define that or is the 
standard ACL enough?

Thanks for the pointers!
Scott

----- Original Message ----- 
From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
To: "Scott Granados" <gsgranados at comcast.net>; "Ryan West" 
<rwest at zyedge.com>; <cisco-nsp at puck.nether.net>
Sent: Wednesday, September 02, 2009 10:33 AM
Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel


Hello Ryan:

Without the no-nat on the ASA side it will try to NAT the traffic before
putting it down the tunnel.  So, you're remove side is looking for the
10. Addresses, but it's going to see traffic coming from the static
outside, NAT'd address.  Thus, the tunnel won't come up because your
proposals don't match.

Mike

--
Michael K. Smith - CISSP, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Wednesday, September 02, 2009 9:45 AM
To: Ryan West; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi, so right now my Pix in the field is pointing at a VPN 3000 so I
can't
take that path down until after hours but I will to capture the debug
data.

A show ver on the asa shows device manager V5.0.7

The field pix shows V6.3
I have access to both ends so updating the firmware is definitely an
option.
Any suggested version?

On the ASA side I do not have a no nat statement at all.  I never
configured
NAT because this device isn't beingused for any features other than a
VPN
access device with split tunneling enabled for the clients.
On the NY pix side the nat config and acl are as follows.

global (outside) 1 208.x.x.100-208.x.x.115 netmask 255.255.255.224
global (outside) 1 208.x.x.99 netmask 255.255.255.224
nat (inside) 0 access-list vpn-1
nat (inside) 1 0.0.0.0 0.0.0.0 0 0

access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
255.255.240.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
255.254.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
255.255.0.0

Thanks
Scott

----- Original Message ----- 
From: "Ryan West" <rwest at zyedge.com>
To: "Scott Granados" <gsgranados at comcast.net>;
<cisco-nsp at puck.nether.net>
Sent: Wednesday, September 02, 2009 6:15 AM
Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel


Scott,

Can you provide debugs from the ASA, code versions on both devices and
your
associated no-nat ACLs?

Assuming you have nothing else logging to monitor, you can enable
'logging
class vpn monitor debug' and throw up a term mon to gather inbound
messages
to the ASA from the PIX side.  You can gather the information on the PIX

with a debug cry isa 2 and then initiate interesting traffic from the
ASA
using the following, the more valuable information will be on the
receiving
end.  It really doesn't matter which side you enable as the receiver,
but I
try to stay away from pre 7.x code on the PIXes.

packet-tracer input inside icmp 10.1.0.10 8 0 10.18.15.10 detailed

Phase: 10 or 11 should be subtype encrypt.  If it fails the first time,
run
it again, the negotiation process causes the first packet to fail as the

tunnel is being brought.  This type of traffic will also give you your
debug
information and help you figure out where the failure is.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Tuesday, September 01, 2009 8:29 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi, I have a Pix out in the field and an ASA5520 that I'm trying to
configure to pass L2L traffic.  I keep getting an error that says
IKEV1 IP=a.b.c.d removing peer from peer table failed, no match
ip=a.b.c.d unable to remove peer table entry

What am I doing wrong?

Here are the important config bits

asa-5520
crypto map
crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac
crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac
crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac
crypto dynamic-map dynmap 10 set transform-set vpn-transform1
vpn-transform2
vpn-transform3
crypto dynamic-map dynmap 10 set reverse-route
crypto map vpn-ra-map 10 match address ny-vpn-acl
crypto map vpn-ra-map 10 set peer ny-fw-outside
crypto map vpn-ra-map 10 set transform-set vpn-transform2
crypto map vpn-ra-map 10 set reverse-route
crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap
crypto map vpn-ra-map interface outside

ISAKMP

isakmp enable outside
isakmp policy 5 authentication pre-share
isakmp policy 5 encryption aes-256
isakmp policy 5 hash sha
isakmp policy 5 group 7
isakmp policy 5 lifetime 3600
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption aes-256
isakmp policy 10 hash sha
isakmp policy 10 group 5
isakmp policy 10 lifetime 3600
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 3600
isakmp policy 30 authentication pre-share
isakmp policy 30 encryption aes-192
isakmp policy 30 hash md5
isakmp policy 30 group 2
isakmp policy 30 lifetime 28800
isakmp nat-traversal  20
isakmp reload-wait

and the acl
access-list ny-vpn-acl extended permit ip 10.1.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.18.0.0 255.255.254.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.14.0.0 255.254.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 157.254.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 141.11.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.11.0.0 255.255.0.0
10.18.15.0
255.255.255.192

TUNNEL GROUP

tunnel-group 208.37.161.98 type ipsec-l2l
tunnel-group 208.37.161.98 general-attributes
 tunnel-group 208.37.161.98 ipsec-attributes
 pre-shared-key *
 peer-id-validate nocheck

PIX

CRYPTO MAP and ISAKMP

crypto ipsec transform-set set1 esp-aes-192 esp-md5-hmac
crypto map map1 10 ipsec-isakmp
crypto map map1 10 match address vpn-1
crypto map map1 10 set peer vpnc
crypto map map1 10 set transform-set set1
crypto map map1 interface outside
isakmp enable outside
isakmp key *
 address vpnc netmask 255.255.255.255
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption aes
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 28800

ACL
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
255.255.240.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
255.254.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
255.255.0.0

)note on the ASA I use individual /24's and shortened the ACL for ease
of
reasing.  I do this to exclued 10.18.14.0/24 from the tunnels since that
houses the ASA's inside interface and client access)

Any pointers would be appreciated.

Thanks
Scott

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From mksmith at adhost.com  Wed Sep  2 13:47:49 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Wed, 2 Sep 2009 10:47:49 -0700
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
In-Reply-To: <012501ca2bf4$ec98c550$2208120a@am.thmulti.com>
References: <000501ca2b64$54ea36c0$0202fea9@am.thmulti.com><6E21B2BDEF6E714EA0B5BA8D5D0E1401248E269EB4@zy-ex1.zyedge.local>
	<00ea01ca2bec$cc3c98c0$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347A7@ad-exh01.adhost.lan>
	<012501ca2bf4$ec98c550$2208120a@am.thmulti.com>
Message-ID: <17838240D9A5544AAA5FF95F8D520316069347B1@ad-exh01.adhost.lan>

Hi Scott:

No, if you use the no-nat below, *all* traffic from 10.18.0.0/24 will
not be NAT'd, regardless of the destination.  What you want is:

Access-list nonat permit ip 10.18.0.0 255.255.255.0 <remote subnet>
<remote mask>

In looking at your post below, I think that would be:

Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.15.0
255.255.255.192

I should note that the mask on the remote side for the 10.18.0.0 subnet
is a /20, not a /24.

Regards,

Mike

--
Michael K. Smith - CISSP, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


-----Original Message-----
From: Scott Granados [mailto:gsgranados at comcast.net] 
Sent: Wednesday, September 02, 2009 10:44 AM
To: Michael K. Smith - Adhost; Ryan West; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi Mike, to follow up on this, I do have existing clients working now.
For 
the nonat rule would I create a sepperate ACL for each target or would a

basic acl like I use for the split tunneling do the trick?

either
access-list ny-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.0

255.255.255.192
or would
access-list nonat standard permit 10.18.0.0 255.255.255.0

I have several different targets so how would one define that or is the 
standard ACL enough?

Thanks for the pointers!
Scott

----- Original Message ----- 
From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
To: "Scott Granados" <gsgranados at comcast.net>; "Ryan West" 
<rwest at zyedge.com>; <cisco-nsp at puck.nether.net>
Sent: Wednesday, September 02, 2009 10:33 AM
Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel


Hello Ryan:

Without the no-nat on the ASA side it will try to NAT the traffic before
putting it down the tunnel.  So, you're remove side is looking for the
10. Addresses, but it's going to see traffic coming from the static
outside, NAT'd address.  Thus, the tunnel won't come up because your
proposals don't match.

Mike

--
Michael K. Smith - CISSP, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Wednesday, September 02, 2009 9:45 AM
To: Ryan West; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi, so right now my Pix in the field is pointing at a VPN 3000 so I
can't
take that path down until after hours but I will to capture the debug
data.

A show ver on the asa shows device manager V5.0.7

The field pix shows V6.3
I have access to both ends so updating the firmware is definitely an
option.
Any suggested version?

On the ASA side I do not have a no nat statement at all.  I never
configured
NAT because this device isn't beingused for any features other than a
VPN
access device with split tunneling enabled for the clients.
On the NY pix side the nat config and acl are as follows.

global (outside) 1 208.x.x.100-208.x.x.115 netmask 255.255.255.224
global (outside) 1 208.x.x.99 netmask 255.255.255.224
nat (inside) 0 access-list vpn-1
nat (inside) 1 0.0.0.0 0.0.0.0 0 0

access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
255.255.240.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
255.254.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
255.255.0.0

Thanks
Scott

----- Original Message ----- 
From: "Ryan West" <rwest at zyedge.com>
To: "Scott Granados" <gsgranados at comcast.net>;
<cisco-nsp at puck.nether.net>
Sent: Wednesday, September 02, 2009 6:15 AM
Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel


Scott,

Can you provide debugs from the ASA, code versions on both devices and
your
associated no-nat ACLs?

Assuming you have nothing else logging to monitor, you can enable
'logging
class vpn monitor debug' and throw up a term mon to gather inbound
messages
to the ASA from the PIX side.  You can gather the information on the PIX

with a debug cry isa 2 and then initiate interesting traffic from the
ASA
using the following, the more valuable information will be on the
receiving
end.  It really doesn't matter which side you enable as the receiver,
but I
try to stay away from pre 7.x code on the PIXes.

packet-tracer input inside icmp 10.1.0.10 8 0 10.18.15.10 detailed

Phase: 10 or 11 should be subtype encrypt.  If it fails the first time,
run
it again, the negotiation process causes the first packet to fail as the

tunnel is being brought.  This type of traffic will also give you your
debug
information and help you figure out where the failure is.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Tuesday, September 01, 2009 8:29 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi, I have a Pix out in the field and an ASA5520 that I'm trying to
configure to pass L2L traffic.  I keep getting an error that says
IKEV1 IP=a.b.c.d removing peer from peer table failed, no match
ip=a.b.c.d unable to remove peer table entry

What am I doing wrong?

Here are the important config bits

asa-5520
crypto map
crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac
crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac
crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac
crypto dynamic-map dynmap 10 set transform-set vpn-transform1
vpn-transform2
vpn-transform3
crypto dynamic-map dynmap 10 set reverse-route
crypto map vpn-ra-map 10 match address ny-vpn-acl
crypto map vpn-ra-map 10 set peer ny-fw-outside
crypto map vpn-ra-map 10 set transform-set vpn-transform2
crypto map vpn-ra-map 10 set reverse-route
crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap
crypto map vpn-ra-map interface outside

ISAKMP

isakmp enable outside
isakmp policy 5 authentication pre-share
isakmp policy 5 encryption aes-256
isakmp policy 5 hash sha
isakmp policy 5 group 7
isakmp policy 5 lifetime 3600
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption aes-256
isakmp policy 10 hash sha
isakmp policy 10 group 5
isakmp policy 10 lifetime 3600
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 3600
isakmp policy 30 authentication pre-share
isakmp policy 30 encryption aes-192
isakmp policy 30 hash md5
isakmp policy 30 group 2
isakmp policy 30 lifetime 28800
isakmp nat-traversal  20
isakmp reload-wait

and the acl
access-list ny-vpn-acl extended permit ip 10.1.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.18.0.0 255.255.254.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.14.0.0 255.254.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 157.254.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 141.11.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.11.0.0 255.255.0.0
10.18.15.0
255.255.255.192

TUNNEL GROUP

tunnel-group 208.37.161.98 type ipsec-l2l
tunnel-group 208.37.161.98 general-attributes
 tunnel-group 208.37.161.98 ipsec-attributes
 pre-shared-key *
 peer-id-validate nocheck

PIX

CRYPTO MAP and ISAKMP

crypto ipsec transform-set set1 esp-aes-192 esp-md5-hmac
crypto map map1 10 ipsec-isakmp
crypto map map1 10 match address vpn-1
crypto map map1 10 set peer vpnc
crypto map map1 10 set transform-set set1
crypto map map1 interface outside
isakmp enable outside
isakmp key *
 address vpnc netmask 255.255.255.255
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption aes
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 28800

ACL
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
255.255.240.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
255.254.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
255.255.0.0

)note on the ASA I use individual /24's and shortened the ACL for ease
of
reasing.  I do this to exclued 10.18.14.0/24 from the tunnels since that
houses the ASA's inside interface and client access)

Any pointers would be appreciated.

Thanks
Scott

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From gsgranados at comcast.net  Wed Sep  2 14:01:42 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Wed, 2 Sep 2009 11:01:42 -0700
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
References: <000501ca2b64$54ea36c0$0202fea9@am.thmulti.com><6E21B2BDEF6E714EA0B5BA8D5D0E1401248E269EB4@zy-ex1.zyedge.local>
	<00ea01ca2bec$cc3c98c0$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347A7@ad-exh01.adhost.lan>
	<012501ca2bf4$ec98c550$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347B1@ad-exh01.adhost.lan>
Message-ID: <013501ca2bf7$74241a40$2208120a@am.thmulti.com>

Hi Michael, thanks but one thing I'm not clear on.

Suppose I have destinations of
10.18.15.0/26 10.18.15.192/26 10.18.14.0/24 etc.
In other words my possible destinations can be different.  If I use your 
example what happens if traffic has the proper source but a destination of 
10.18.15.192/26 or if traffic is destined to a client on 10.18.14.0/24? It 
won't match the ACL correct?


----- Original Message ----- 
From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
To: "Scott Granados" <gsgranados at comcast.net>; "Ryan West" 
<rwest at zyedge.com>; <cisco-nsp at puck.nether.net>
Sent: Wednesday, September 02, 2009 10:47 AM
Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel


Hi Scott:

No, if you use the no-nat below, *all* traffic from 10.18.0.0/24 will
not be NAT'd, regardless of the destination.  What you want is:

Access-list nonat permit ip 10.18.0.0 255.255.255.0 <remote subnet>
<remote mask>

In looking at your post below, I think that would be:

Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.15.0
255.255.255.192

I should note that the mask on the remote side for the 10.18.0.0 subnet
is a /20, not a /24.

Regards,

Mike

--
Michael K. Smith - CISSP, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


-----Original Message-----
From: Scott Granados [mailto:gsgranados at comcast.net]
Sent: Wednesday, September 02, 2009 10:44 AM
To: Michael K. Smith - Adhost; Ryan West; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi Mike, to follow up on this, I do have existing clients working now.
For
the nonat rule would I create a sepperate ACL for each target or would a

basic acl like I use for the split tunneling do the trick?

either
access-list ny-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.0

255.255.255.192
or would
access-list nonat standard permit 10.18.0.0 255.255.255.0

I have several different targets so how would one define that or is the
standard ACL enough?

Thanks for the pointers!
Scott

----- Original Message ----- 
From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
To: "Scott Granados" <gsgranados at comcast.net>; "Ryan West"
<rwest at zyedge.com>; <cisco-nsp at puck.nether.net>
Sent: Wednesday, September 02, 2009 10:33 AM
Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel


Hello Ryan:

Without the no-nat on the ASA side it will try to NAT the traffic before
putting it down the tunnel.  So, you're remove side is looking for the
10. Addresses, but it's going to see traffic coming from the static
outside, NAT'd address.  Thus, the tunnel won't come up because your
proposals don't match.

Mike

--
Michael K. Smith - CISSP, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Wednesday, September 02, 2009 9:45 AM
To: Ryan West; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi, so right now my Pix in the field is pointing at a VPN 3000 so I
can't
take that path down until after hours but I will to capture the debug
data.

A show ver on the asa shows device manager V5.0.7

The field pix shows V6.3
I have access to both ends so updating the firmware is definitely an
option.
Any suggested version?

On the ASA side I do not have a no nat statement at all.  I never
configured
NAT because this device isn't beingused for any features other than a
VPN
access device with split tunneling enabled for the clients.
On the NY pix side the nat config and acl are as follows.

global (outside) 1 208.x.x.100-208.x.x.115 netmask 255.255.255.224
global (outside) 1 208.x.x.99 netmask 255.255.255.224
nat (inside) 0 access-list vpn-1
nat (inside) 1 0.0.0.0 0.0.0.0 0 0

access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
255.255.240.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
255.254.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
255.255.0.0

Thanks
Scott

----- Original Message ----- 
From: "Ryan West" <rwest at zyedge.com>
To: "Scott Granados" <gsgranados at comcast.net>;
<cisco-nsp at puck.nether.net>
Sent: Wednesday, September 02, 2009 6:15 AM
Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel


Scott,

Can you provide debugs from the ASA, code versions on both devices and
your
associated no-nat ACLs?

Assuming you have nothing else logging to monitor, you can enable
'logging
class vpn monitor debug' and throw up a term mon to gather inbound
messages
to the ASA from the PIX side.  You can gather the information on the PIX

with a debug cry isa 2 and then initiate interesting traffic from the
ASA
using the following, the more valuable information will be on the
receiving
end.  It really doesn't matter which side you enable as the receiver,
but I
try to stay away from pre 7.x code on the PIXes.

packet-tracer input inside icmp 10.1.0.10 8 0 10.18.15.10 detailed

Phase: 10 or 11 should be subtype encrypt.  If it fails the first time,
run
it again, the negotiation process causes the first packet to fail as the

tunnel is being brought.  This type of traffic will also give you your
debug
information and help you figure out where the failure is.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Tuesday, September 01, 2009 8:29 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi, I have a Pix out in the field and an ASA5520 that I'm trying to
configure to pass L2L traffic.  I keep getting an error that says
IKEV1 IP=a.b.c.d removing peer from peer table failed, no match
ip=a.b.c.d unable to remove peer table entry

What am I doing wrong?

Here are the important config bits

asa-5520
crypto map
crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac
crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac
crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac
crypto dynamic-map dynmap 10 set transform-set vpn-transform1
vpn-transform2
vpn-transform3
crypto dynamic-map dynmap 10 set reverse-route
crypto map vpn-ra-map 10 match address ny-vpn-acl
crypto map vpn-ra-map 10 set peer ny-fw-outside
crypto map vpn-ra-map 10 set transform-set vpn-transform2
crypto map vpn-ra-map 10 set reverse-route
crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap
crypto map vpn-ra-map interface outside

ISAKMP

isakmp enable outside
isakmp policy 5 authentication pre-share
isakmp policy 5 encryption aes-256
isakmp policy 5 hash sha
isakmp policy 5 group 7
isakmp policy 5 lifetime 3600
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption aes-256
isakmp policy 10 hash sha
isakmp policy 10 group 5
isakmp policy 10 lifetime 3600
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 3600
isakmp policy 30 authentication pre-share
isakmp policy 30 encryption aes-192
isakmp policy 30 hash md5
isakmp policy 30 group 2
isakmp policy 30 lifetime 28800
isakmp nat-traversal  20
isakmp reload-wait

and the acl
access-list ny-vpn-acl extended permit ip 10.1.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.18.0.0 255.255.254.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.14.0.0 255.254.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 157.254.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 141.11.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.11.0.0 255.255.0.0
10.18.15.0
255.255.255.192

TUNNEL GROUP

tunnel-group 208.37.161.98 type ipsec-l2l
tunnel-group 208.37.161.98 general-attributes
 tunnel-group 208.37.161.98 ipsec-attributes
 pre-shared-key *
 peer-id-validate nocheck

PIX

CRYPTO MAP and ISAKMP

crypto ipsec transform-set set1 esp-aes-192 esp-md5-hmac
crypto map map1 10 ipsec-isakmp
crypto map map1 10 match address vpn-1
crypto map map1 10 set peer vpnc
crypto map map1 10 set transform-set set1
crypto map map1 interface outside
isakmp enable outside
isakmp key *
 address vpnc netmask 255.255.255.255
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption aes
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 28800

ACL
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
255.255.240.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
255.254.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
255.255.0.0

)note on the ASA I use individual /24's and shortened the ACL for ease
of
reasing.  I do this to exclued 10.18.14.0/24 from the tunnels since that
houses the ASA's inside interface and client access)

Any pointers would be appreciated.

Thanks
Scott

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From dcp at dcptech.com  Wed Sep  2 13:21:34 2009
From: dcp at dcptech.com (David Prall)
Date: Wed, 2 Sep 2009 13:21:34 -0400
Subject: [c-nsp] do i *need* DFCs on the 6500?
In-Reply-To: <F3318834F1F89D46857972DD4B411D70B0070F36@EXCHANGE.thenap.com>
References: <20090902111616.GA6588@lboro.ac.uk>	<4A9E6786.5010901@justinshore.com>
	<F3318834F1F89D46857972DD4B411D70B0070F36@EXCHANGE.thenap.com>
Message-ID: <002a01ca2bf1$e4849f90$ad8ddeb0$@com>

Drew,
Have a look at using "mls rate-limit all ttl-failure"

Here is a paper I worked on, more with an Enterprise feel.
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper
_c11_553261.html

David

--
http://dcp.dcptech.com
 

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Drew Weaver
> Sent: Wednesday, September 02, 2009 8:48 AM
> To: 'Justin Shore'; Alan Buxey
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] do i *need* DFCs on the 6500?
> 
> Not to thread hijack here, but speaking of withstanding DoS attacks,
> has anyone seen any decent published baseline configurations for CoPP
> to deflect things similar to TTL Expiry attacks and the like? Perhaps
> some sort of template they use (if they can share it) would be really
> nice.
> 
> I would just like to see what others are doing.
> 
> -Drew
> 
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Justin Shore
> Sent: Wednesday, September 02, 2009 8:40 AM
> To: Alan Buxey
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] do i *need* DFCs on the 6500?
> 
> You eluded to one of my strongest selling points on DFCs though I don't
> think you made that particular connection yet.  DFCs offload QoS to the
> LC as you said.  That also means that CoPP is also handled in hardware
> if you have DFCs in place since it requires MLS QoS on that platform.
> Ie, if your 6500/7600 is going to be publicly-accessible on the
> Internet
> in any capacity and you want it to be able to use CoPP to withstand a
> targeted DoS attack then DFCs are not optional, they're critical.
> 
> The others on the list can probably give you much more in-depth views
> on
> the other aspects of the card but I found CoPP to be a big enough
> selling point.  It wouldn't be good is a simple little DoS attack took
> down my core 7600s.
> 
> Justin
> 
> 
> Alan Buxey wrote:
> > hi,
> >
> > okay, from the background of I know what the DFC is and how it
> > operates etc... i know I want them - however, I need to justify
> > the upgrade/part cost to sort out a couple of 6500's.  in some of
> > our 6500's, the 10G blades have DFCs already...but several 6724's
> dont
> > (they just have CFC). ...as i said, I want them, but need to get
> > some management/funding buy-in - and they dont want the 'what it
> > does' information - they want some hard and fast facts that Cisco
> dont
> > sem to want to tell me ..... so, the question is
> >
> > 1) is there any way of showing the sup720
> strain/utilisation...particularly
> > is there a way of showing DFC usage on the blades where we have them?
> >
> > 2) it offloads IPv6 and QoS - we're into both of those (and more so
> over the
> > next year) - any particular insights into QoS performance/issues
> without
> > DFC ? any throughput figures for IPv6 ?
> >
> > (i know that with CFC we're limited to the backplane (32mpps?) and we
> get ~ 48mpps
> > per blade with DFC)
> >
> > ...or could it be that DFC's are only really useful to a particular
> deployment
> > and I just *think* i need them?  ;-)
> >
> > alan
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From jim at jamesberwick.com  Wed Sep  2 14:05:51 2009
From: jim at jamesberwick.com (James Berwick)
Date: Wed, 02 Sep 2009 14:05:51 -0400
Subject: [c-nsp] ATM packet loss
Message-ID: <4A9EB3FF.9070805@jamesberwick.com>

Hello!

We have a 7500 series router, RSP16 with IOS Version 12.3(21) 
terminating a bunch of ATM circuits.

We have 3 ATM DS3s terminating on PA-A3-T3 cards, and an ATM OC3 
terminating on a PA-A3-OC3-SMI.  All line cards are VIP-480s.

The problem we are seeing is customers with PVCs on our ATM OC3 have 
begun getting extremely poor throughput.  30mbit PVCs that can pull at 
most 3-5mbit/sec.  Overall utilization of the ATM OC3 dropped from 
around 90mbit/sec last year to around 25mbit/sec this year.  We've had 
the LEC test the OC3 and the customer side (DS3s to multiple customers) 
at the ATM PVC level and show us results that the OC3 is able to push 
155mbit/sec worth of cells and the DS3s are able to push 45mbit/sec 
worth of cells.  There are no errors on the interfaces and no AAL5 
errors on the PVCs.  We're completely at a loss.  One commonality we've 
found is that when we ping the opposite side of a customer on one of the 
ATM DS3s in our chassis with large packets it works fine.  Pinging a 
customer on our OC3 with any packet larger than 576 bytes intermittently 
fails.

ATM DS3:
er02.penn-nj#ping x.x.x.x size 577 repeat 1000

Type escape sequence to abort.
Sending 1000, 577-byte ICMP Echos to x.x.x.x, timeout is 2 seconds:
...
Success rate is 100 percent (1000/1000), round-trip min/avg/max = 1/4/40 ms


ATM OC3:
er02.penn-nj#ping x.x.x.x size 577 repeat 1000

Type escape sequence to abort.
Sending 1000, 577-byte ICMP Echos to x.x.x.x, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!
!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (996/1000), round-trip min/avg/max = 1/2/8 ms

Same destination as above with 576 byte pings:
Success rate is 100 percent (1000/1000), round-trip min/avg/max = 1/2/8 ms

This is the ATM OC3 config:
interface ATM1/1/0
 mac-address 0000.0c71.1148
 bandwidth 155000
 no ip address
 load-interval 30
 atm ilmi-keepalive
end

This is a PVC config (all are very similar and all show identical 
performance):
interface ATM1/1/0.36 point-to-point
 bandwidth 45000
 ip address x.x.x.x 255.255.255.252
 pvc 1/141
  ubr 44209
  oam-pvc manage
  oam retry 3 5 1
  encapsulation aal5snap
 !
end


Thanks anyone in advance for any suggestions!

From michaelfox100 at gmail.com  Wed Sep  2 14:56:18 2009
From: michaelfox100 at gmail.com (Michael Fox)
Date: Wed, 2 Sep 2009 13:56:18 -0500
Subject: [c-nsp] Geographically dispersed ASA failover?
In-Reply-To: <79AF0C3901752A49881FE4CB31F7AA40016ECC39@abn-borg2.NETABN.LOCAL>
References: <79AF0C3901752A49881FE4CB31F7AA40016ECC39@abn-borg2.NETABN.LOCAL>
Message-ID: <b2582a5a0909021156j2b4ed135qff2da198d576c172@mail.gmail.com>

As long as your latency is under 10ms, you should be fine.
>From Cisco's site: "For optimum performance when using long distance LAN
failover, the latency for the failover link should be less than 10
milliseconds and no more than 250 milliseconds. If latency is more than 10
milliseconds, some performance degradation occurs due to retransmission of
failover messages.
http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/failover.html#wp1052476

Michael
<http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/failover.html#wp1052476>

On Wed, Sep 2, 2009 at 11:38 AM, Michael Malitsky <malitsky at netabn.com>wrote:

> Hello,
>
> Does anyone know if the ASA failover feature supports a setup where the
> ASAs are in geographically different locations?  Specifically, I have
> two data centers about 30 miles apart, connected by a 50Mb metro
> ethernet link with latency under 10ms.
>
> Thanks,
> Michael Malitsky
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From swmike at swm.pp.se  Wed Sep  2 15:01:15 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 2 Sep 2009 21:01:15 +0200 (CEST)
Subject: [c-nsp] ATM packet loss
In-Reply-To: <4A9EB3FF.9070805@jamesberwick.com>
References: <4A9EB3FF.9070805@jamesberwick.com>
Message-ID: <alpine.DEB.1.10.0909022058410.20521@uplift.swm.pp.se>

On Wed, 2 Sep 2009, James Berwick wrote:

> works fine.  Pinging a customer on our OC3 with any packet larger than 576 
> bytes intermittently fails.
>
> This is the ATM OC3 config:
> interface ATM1/1/0
> mac-address 0000.0c71.1148
> bandwidth 155000
> no ip address
> load-interval 30
> atm ilmi-keepalive
> end

First thing I'd try here would be to configure some ubr value on the OC3, 
set it to 120 megabit/s or something like that. If that helps, increase 
until you get close to wirespeed and see if the problem creeps up the 
higher the UBR. The behaviour you're seeing is alike to what I've seen 
when there is a cell policer dropping cells somewhere.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se

From chris at lavin-llc.com  Wed Sep  2 14:27:32 2009
From: chris at lavin-llc.com (chris at lavin-llc.com)
Date: Wed, 02 Sep 2009 14:27:32 -0400
Subject: [c-nsp] OT - Dark Fiber
Message-ID: <48593.1251916052@lavin-llc.com>

I was curious to know if there are different ways to go about purchasing dark fiber. If you have Site A and Site B only a few miles apart and you're 
happy to provide the light, how do you get the fiber? Not expecting to obtain right-of-way/permits/ditch digger. Do you lease (meaning paying a MRC) or 
is it 'purchased' (meaning a NRC)?

Thanks,
-chris




From rwest at zyedge.com  Wed Sep  2 14:50:45 2009
From: rwest at zyedge.com (Ryan West)
Date: Wed, 2 Sep 2009 14:50:45 -0400
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
In-Reply-To: <012501ca2bf4$ec98c550$2208120a@am.thmulti.com>
References: <000501ca2b64$54ea36c0$0202fea9@am.thmulti.com><6E21B2BDEF6E714EA0B5BA8D5D0E1401248E269EB4@zy-ex1.zyedge.local>
	<00ea01ca2bec$cc3c98c0$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347A7@ad-exh01.adhost.lan>
	<012501ca2bf4$ec98c550$2208120a@am.thmulti.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248E269EF5@zy-ex1.zyedge.local>

Scott,

Ideally, you'll want to use a new ACE for each phase2 tunnel and even though you have a single crypto map L2L interesting traffic ACL, I would still separate them out.  For example, have an ACL called vpn_ny and ACL called inside_nonat, then as you add new partners, you'll have a new interesting ACL and a new addition to your nonat ACL.

As for versions, if the PIX is a 515, that is a scary upgrade and will most likely require someone onsite to upgrade it from the bootloader.  If it's a 515E, the upgrade can be completed with a lot less risk.  Either option requires a minimum memory upgrade to 64 Meg.  We have a lot of luck with 7.2.4(33) interim release.

-ryan

-----Original Message-----
From: Scott Granados [mailto:gsgranados at comcast.net] 
Sent: Wednesday, September 02, 2009 1:44 PM
To: Michael K. Smith - Adhost; Ryan West; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi Mike, to follow up on this, I do have existing clients working now.  For 
the nonat rule would I create a sepperate ACL for each target or would a 
basic acl like I use for the split tunneling do the trick?

either
access-list ny-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.0 
255.255.255.192
or would
access-list nonat standard permit 10.18.0.0 255.255.255.0

I have several different targets so how would one define that or is the 
standard ACL enough?

Thanks for the pointers!
Scott

----- Original Message ----- 
From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
To: "Scott Granados" <gsgranados at comcast.net>; "Ryan West" 
<rwest at zyedge.com>; <cisco-nsp at puck.nether.net>
Sent: Wednesday, September 02, 2009 10:33 AM
Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel


Hello Ryan:

Without the no-nat on the ASA side it will try to NAT the traffic before
putting it down the tunnel.  So, you're remove side is looking for the
10. Addresses, but it's going to see traffic coming from the static
outside, NAT'd address.  Thus, the tunnel won't come up because your
proposals don't match.

Mike

--
Michael K. Smith - CISSP, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Wednesday, September 02, 2009 9:45 AM
To: Ryan West; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi, so right now my Pix in the field is pointing at a VPN 3000 so I
can't
take that path down until after hours but I will to capture the debug
data.

A show ver on the asa shows device manager V5.0.7

The field pix shows V6.3
I have access to both ends so updating the firmware is definitely an
option.
Any suggested version?

On the ASA side I do not have a no nat statement at all.  I never
configured
NAT because this device isn't beingused for any features other than a
VPN
access device with split tunneling enabled for the clients.
On the NY pix side the nat config and acl are as follows.

global (outside) 1 208.x.x.100-208.x.x.115 netmask 255.255.255.224
global (outside) 1 208.x.x.99 netmask 255.255.255.224
nat (inside) 0 access-list vpn-1
nat (inside) 1 0.0.0.0 0.0.0.0 0 0

access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
255.255.240.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
255.254.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
255.255.0.0

Thanks
Scott

----- Original Message ----- 
From: "Ryan West" <rwest at zyedge.com>
To: "Scott Granados" <gsgranados at comcast.net>;
<cisco-nsp at puck.nether.net>
Sent: Wednesday, September 02, 2009 6:15 AM
Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel


Scott,

Can you provide debugs from the ASA, code versions on both devices and
your
associated no-nat ACLs?

Assuming you have nothing else logging to monitor, you can enable
'logging
class vpn monitor debug' and throw up a term mon to gather inbound
messages
to the ASA from the PIX side.  You can gather the information on the PIX

with a debug cry isa 2 and then initiate interesting traffic from the
ASA
using the following, the more valuable information will be on the
receiving
end.  It really doesn't matter which side you enable as the receiver,
but I
try to stay away from pre 7.x code on the PIXes.

packet-tracer input inside icmp 10.1.0.10 8 0 10.18.15.10 detailed

Phase: 10 or 11 should be subtype encrypt.  If it fails the first time,
run
it again, the negotiation process causes the first packet to fail as the

tunnel is being brought.  This type of traffic will also give you your
debug
information and help you figure out where the failure is.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Tuesday, September 01, 2009 8:29 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi, I have a Pix out in the field and an ASA5520 that I'm trying to
configure to pass L2L traffic.  I keep getting an error that says
IKEV1 IP=a.b.c.d removing peer from peer table failed, no match
ip=a.b.c.d unable to remove peer table entry

What am I doing wrong?

Here are the important config bits

asa-5520
crypto map
crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac
crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac
crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac
crypto dynamic-map dynmap 10 set transform-set vpn-transform1
vpn-transform2
vpn-transform3
crypto dynamic-map dynmap 10 set reverse-route
crypto map vpn-ra-map 10 match address ny-vpn-acl
crypto map vpn-ra-map 10 set peer ny-fw-outside
crypto map vpn-ra-map 10 set transform-set vpn-transform2
crypto map vpn-ra-map 10 set reverse-route
crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap
crypto map vpn-ra-map interface outside

ISAKMP

isakmp enable outside
isakmp policy 5 authentication pre-share
isakmp policy 5 encryption aes-256
isakmp policy 5 hash sha
isakmp policy 5 group 7
isakmp policy 5 lifetime 3600
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption aes-256
isakmp policy 10 hash sha
isakmp policy 10 group 5
isakmp policy 10 lifetime 3600
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 3600
isakmp policy 30 authentication pre-share
isakmp policy 30 encryption aes-192
isakmp policy 30 hash md5
isakmp policy 30 group 2
isakmp policy 30 lifetime 28800
isakmp nat-traversal  20
isakmp reload-wait

and the acl
access-list ny-vpn-acl extended permit ip 10.1.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.18.0.0 255.255.254.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.14.0.0 255.254.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 157.254.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 141.11.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.11.0.0 255.255.0.0
10.18.15.0
255.255.255.192

TUNNEL GROUP

tunnel-group 208.37.161.98 type ipsec-l2l
tunnel-group 208.37.161.98 general-attributes
 tunnel-group 208.37.161.98 ipsec-attributes
 pre-shared-key *
 peer-id-validate nocheck

PIX

CRYPTO MAP and ISAKMP

crypto ipsec transform-set set1 esp-aes-192 esp-md5-hmac
crypto map map1 10 ipsec-isakmp
crypto map map1 10 match address vpn-1
crypto map map1 10 set peer vpnc
crypto map map1 10 set transform-set set1
crypto map map1 interface outside
isakmp enable outside
isakmp key *
 address vpnc netmask 255.255.255.255
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption aes
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 28800

ACL
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
255.255.240.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
255.254.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
255.255.0.0

)note on the ASA I use individual /24's and shortened the ACL for ease
of
reasing.  I do this to exclued 10.18.14.0/24 from the tunnels since that
houses the ASA's inside interface and client access)

Any pointers would be appreciated.

Thanks
Scott

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From peter at rathlev.dk  Wed Sep  2 15:36:27 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Wed, 02 Sep 2009 21:36:27 +0200
Subject: [c-nsp] Management stuff in VRFs
Message-ID: <1251920188.2923.4.camel@abehat.net.rm.dk>

I'm a little curious since there have been so many threads about running
management stuff in VRFs. I've until now considered VRFs something for
customers only; management is in the global table.

Is management from a VRF to be considered "best practice"?

What are the benefits from using a VRF for this?

I assume everyone uses infrastructure ACLs so the VRF thingy shouldn't
be any more "secure". Or should it?

Regards,
Peter





From rsm at fast-serv.com  Wed Sep  2 15:37:36 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Wed, 2 Sep 2009 15:37:36 -0400
Subject: [c-nsp] OT - Dark Fiber
In-Reply-To: <48593.1251916052@lavin-llc.com>
References: <48593.1251916052@lavin-llc.com>
Message-ID: <20090902193606.M40835@fast-serv.com>

It's almost always MRC + NRC.

In our situation level3 was on site near both locations so we pay them xxxx
per month for the fiber plus the setup fee.  If you don't have the same
provider on site or very close to both locations, it gets very expensive both
MRC and NRC.

--
Randy

---------- Original Message -----------
From: <chris at lavin-llc.com>
To: cisco-nsp at puck.nether.net
Sent: Wed, 02 Sep 2009 14:27:32 -0400
Subject: [c-nsp] OT - Dark Fiber

> I was curious to know if there are different ways to go about 
> purchasing dark fiber. If you have Site A and Site B only a few 
> miles apart and you're happy to provide the light, how do you get 
> the fiber? Not expecting to obtain right-of-way/permits/ditch 
> digger. Do you lease (meaning paying a MRC) or is it 'purchased' 
> (meaning a NRC)?
> 
> Thanks,
> -chris
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
------- End of Original Message -------


From rsm at fast-serv.com  Wed Sep  2 15:38:15 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Wed, 2 Sep 2009 15:38:15 -0400
Subject: [c-nsp] ATM packet loss
In-Reply-To: <alpine.DEB.1.10.0909022058410.20521@uplift.swm.pp.se>
References: <4A9EB3FF.9070805@jamesberwick.com>
	<alpine.DEB.1.10.0909022058410.20521@uplift.swm.pp.se>
Message-ID: <20090902193755.M55542@fast-serv.com>

Do you have QOS enabled (mls qos)?

--
Randy

---------- Original Message -----------
From: Mikael Abrahamsson <swmike at swm.pp.se>
To: James Berwick <jim at jamesberwick.com>
Cc: cisco-nsp at puck.nether.net
Sent: Wed, 2 Sep 2009 21:01:15 +0200 (CEST)
Subject: Re: [c-nsp] ATM packet loss

> On Wed, 2 Sep 2009, James Berwick wrote:
> 
> > works fine.  Pinging a customer on our OC3 with any packet larger than 576 
> > bytes intermittently fails.
> >
> > This is the ATM OC3 config:
> > interface ATM1/1/0
> > mac-address 0000.0c71.1148
> > bandwidth 155000
> > no ip address
> > load-interval 30
> > atm ilmi-keepalive
> > end
> 
> First thing I'd try here would be to configure some ubr value on the 
> OC3, set it to 120 megabit/s or something like that. If that helps,
>  increase until you get close to wirespeed and see if the problem 
> creeps up the higher the UBR. The behaviour you're seeing is alike 
> to what I've seen when there is a cell policer dropping cells somewhere.
> 
> -- 
> Mikael Abrahamsson    email: swmike at swm.pp.se
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
------- End of Original Message -------


From streiner at cluebyfour.org  Wed Sep  2 15:40:26 2009
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Wed, 2 Sep 2009 15:40:26 -0400 (EDT)
Subject: [c-nsp] OT - Dark Fiber
In-Reply-To: <48593.1251916052@lavin-llc.com>
References: <48593.1251916052@lavin-llc.com>
Message-ID: <Pine.LNX.4.64.0909021526030.22080@whammy.cluebyfour.org>

On Wed, 2 Sep 2009, chris at lavin-llc.com wrote:

> I was curious to know if there are different ways to go about purchasing
> dark fiber. If you have Site A and Site B only a few miles apart and 
> you're happy to provide the light, how do you get the fiber? Not 
> expecting to obtain right-of-way/permits/ditch digger. Do you lease 
> (meaning paying a MRC) or is it 'purchased' (meaning a NRC)?

In a case like this, it's commonplace to lease fiber from a fiber 
provider.  Depending on your location, there might be several who can 
provide you with the glass you're looking for.  In a scenario like this, 
you're normally leasing the fiber, or possible purchasing a long-term IRU 
(Indefeasible Right to Use).

Charges are normally based on mileage and any necessary construction at 
either/both ends to get the fiber from their existing plant into your 
buildings.  Some providers will amoritize the construction costs into your 
monthly contract rate, while others will require you to pay for the 
construction separately.

Depending on the number of strands you need between points A and B and 
other considerations (multiple routes to provide physical diversity, etc), 
the provider might be willing to build a path for you, but the cost goes 
up dramatically.

Once the fiber path is completely built, make sure the provider gives you 
the results of their tests (2-point loss, OTDR graphs, etc) on the whole 
span.  The performance of the fiber and the type of optics you'll need 
to drive the link over distances of 'a few miles' will normally have much 
more to do with the quality and number of splices than the length of the 
span itself.  I've driven 1000baseLX/LH signal cleanly over fiber paths 
that were longer than 10km as long as the 2-point loss is under the link 
budget for the optics.

jms

From jim at jamesberwick.com  Wed Sep  2 15:59:06 2009
From: jim at jamesberwick.com (James Berwick)
Date: Wed, 02 Sep 2009 15:59:06 -0400
Subject: [c-nsp] ATM packet loss
In-Reply-To: <20090902193755.M55542@fast-serv.com>
References: <4A9EB3FF.9070805@jamesberwick.com>
	<alpine.DEB.1.10.0909022058410.20521@uplift.swm.pp.se>
	<20090902193755.M55542@fast-serv.com>
Message-ID: <4A9ECE8A.8010001@jamesberwick.com>

Nope:
er02.penn-nj#show run | i mls
er02.penn-nj#
er02.penn-nj#show mls rp interface atm 1/1/0
mls not configured on ATM1/1/0
er02.penn-nj#show mls rp interface atm 1/1/0.36
mls not configured on ATM1/1/0.36
er02.penn-nj#show mls rp ip
ip multilayer switching is globally disabled


Randy McAnally wrote:
> Do you have QOS enabled (mls qos)?
>
> --
> Randy
>
> ---------- Original Message -----------
> From: Mikael Abrahamsson <swmike at swm.pp.se>
> To: James Berwick <jim at jamesberwick.com>
> Cc: cisco-nsp at puck.nether.net
> Sent: Wed, 2 Sep 2009 21:01:15 +0200 (CEST)
> Subject: Re: [c-nsp] ATM packet loss
>
>   
>> On Wed, 2 Sep 2009, James Berwick wrote:
>>
>>     
>>> works fine.  Pinging a customer on our OC3 with any packet larger than 576 
>>> bytes intermittently fails.
>>>
>>> This is the ATM OC3 config:
>>> interface ATM1/1/0
>>> mac-address 0000.0c71.1148
>>> bandwidth 155000
>>> no ip address
>>> load-interval 30
>>> atm ilmi-keepalive
>>> end
>>>       
>> First thing I'd try here would be to configure some ubr value on the 
>> OC3, set it to 120 megabit/s or something like that. If that helps,
>>  increase until you get close to wirespeed and see if the problem 
>> creeps up the higher the UBR. The behaviour you're seeing is alike 
>> to what I've seen when there is a cell policer dropping cells somewhere.
>>
>> -- 
>> Mikael Abrahamsson    email: swmike at swm.pp.se
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>     
> ------- End of Original Message -------
>
>
>   


From w3yni1 at gmail.com  Wed Sep  2 15:58:44 2009
From: w3yni1 at gmail.com (Charles Mills)
Date: Wed, 2 Sep 2009 15:58:44 -0400
Subject: [c-nsp] OT - Dark Fiber
In-Reply-To: <48593.1251916052@lavin-llc.com>
References: <48593.1251916052@lavin-llc.com>
Message-ID: <607f1e0a0909021258s54f050a7xdf4ae81498ea57c9@mail.gmail.com>

Depending on the city there are fiber providers doing both dark and
lit services.

In Pittsburgh we currently have two that I deal with that are driving
prices down quite nicely.

Chuck

On Wed, Sep 2, 2009 at 2:27 PM, <chris at lavin-llc.com> wrote:
> I was curious to know if there are different ways to go about purchasing dark fiber. If you have Site A and Site B only a few miles apart and you're
> happy to provide the light, how do you get the fiber? Not expecting to obtain right-of-way/permits/ditch digger. Do you lease (meaning paying a MRC) or
> is it 'purchased' (meaning a NRC)?
>
> Thanks,
> -chris
>
>
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



-- 
=====================================
Charles L. Mills
Westmoreland Co. ARES EC
Amateur Radio Callsign W3YNI
Email: w3yni1 at gmail.com

From matt at overloaded.net  Wed Sep  2 16:13:34 2009
From: matt at overloaded.net (Matt Buford)
Date: Wed, 2 Sep 2009 15:13:34 -0500
Subject: [c-nsp] interfaces flapping QinQ and/or spanning tree
In-Reply-To: <684208.86900.qm@web39701.mail.mud.yahoo.com>
References: <684208.86900.qm@web39701.mail.mud.yahoo.com>
Message-ID: <8e157ab40909021313n1443d04bod0ca5199af2c7d67@mail.gmail.com>

On Tue, Sep 1, 2009 at 7:22 AM, Bruno Filipe <brun0_filipe at yahoo.com> wrote:

> Something Weird is happening to me...the setup is very simple (there's
> nothing fancy) but for some reason I do have my switch ports flapping all
> the time and due to the fact the spanning tree is busy converging whenever
> that happens causing lot of problems...
>


> Syslog OUTPUT
> Sep  1 11:37:37 cat1.lda2.ao.isp.net 2045: Sep  1 11:37:17.823 GMT+1:
> %SW_MATM-4-MACFLAP_NOTIF: Host 0023.3314.0420 in vlan 291 is flapping
> between port Fa0/9 and port Fa0/1
> Sep  1 11:37:37 cat1.lda2.isp.net 2046: Sep  1 11:37:17.932 GMT+1:
> %SW_MATM-4-MACFLAP_NOTIF: Host 0013.8fb8.cb9d in vlan 292 is flapping
> between port Fa0/9 and port Fa0/11
>
>
It isn't clear to me which switch on your diagram is logging this message.
 Is it a switch that is actually doing QinQ?  I have run into problems
before where I had a metro-Ethernet link provided to me by a provider that
used QinQ.  So, none of my switches were speaking QinQ.  The problem I ran
into is that my 6500 switches use the same MAC address for every "interface
vlan" on the switch.  I then had half of my spanning tree roots set to one
switch, and the other half set to the other switch.

This resulted in the same mac address being transmitted in both directions
around my redundant metro-e loop.  None of MY switches ever logged the "is
flapping between..." message, but my provider did get that message logged
constantly.  For me, it just looked like I kept losing connectivity because
whenever the mac address went one way, one half of the vlans worked.  When
it went the other way, the other half of the VLANs worked.

Here's an old diagram I prepared years ago explaining the situation:

http://www.overloaded.net/pics/qinq.gif

You won't run into this problem if a) you never reuse a mac address across
VLANs, or b) all your STP roots are the same, or c) you don't have redundant
links forming a loop that includes QinQ.

The average customer of a QinQ metro-e provider likely won't notice this
issue mostly because of "C".  I suspect most customers of metro-e providers
using QinQ probably aren't using the QinQ based link to form a redundant
loop.  In my case, I almost always need redundant bridging of all VLANs
between datacenters.

Our solution?  We now ask every provider that we might buy metro-e from if
they are using QinQ.  If they say yes, they are disqualified.
 Unfortunately, some say no but turn out to be using it after all.  It is
quite frustrating to spend lots of money and time trying to get a provider
to turn a circuit up in time for a big project only to find that once the
circuit is delivered, we can't turn up redundancy across it because the
circuit is unable to carry reused MAC addresses across different VLANs.

From matt at overloaded.net  Wed Sep  2 16:19:35 2009
From: matt at overloaded.net (Matt Buford)
Date: Wed, 2 Sep 2009 15:19:35 -0500
Subject: [c-nsp] Geographically dispersed ASA failover?
In-Reply-To: <b2582a5a0909021156j2b4ed135qff2da198d576c172@mail.gmail.com>
References: <79AF0C3901752A49881FE4CB31F7AA40016ECC39@abn-borg2.NETABN.LOCAL>
	<b2582a5a0909021156j2b4ed135qff2da198d576c172@mail.gmail.com>
Message-ID: <8e157ab40909021319x535febe3qd8fccc0c0c63642b@mail.gmail.com>

On Wed, Sep 2, 2009 at 1:56 PM, Michael Fox <michaelfox100 at gmail.com> wrote:

> As long as your latency is under 10ms, you should be fine.
> >From Cisco's site: "For optimum performance when using long distance LAN
> failover, the latency for the failover link should be less than 10
> milliseconds and no more than 250 milliseconds. If latency is more than 10
> milliseconds, some performance degradation occurs due to retransmission of
> failover messages.
>
> http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/failover.html#wp1052476
>

I have done this (with low latency circuits).  I have migrated customers
from one city to another nearby city across <5 ms links by bridging their
VLANs across the circuit (outer and inner VLANs), then moving one firewall
of a failover pair one night (leaving things running for a day or two with
failover across datacenters), then the next night failing it over to the
firewall in the new DC and moving the 2nd firewall.  This lets us do
"hitless" firewall migrations from one DC to another.  Downtime for the 1
forced failover required to complete the process is sub-second, and stateful
failover allows connections to survive.

We haven't ever left it split like that long term, but I haven't noticed any
problems in the day-or-two migration situations we've done this for.

From mksmith at adhost.com  Wed Sep  2 16:26:31 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Wed, 2 Sep 2009 13:26:31 -0700
Subject: [c-nsp] OT - Dark Fiber
In-Reply-To: <48593.1251916052@lavin-llc.com>
References: <48593.1251916052@lavin-llc.com>
Message-ID: <17838240D9A5544AAA5FF95F8D520316069347F0@ad-exh01.adhost.lan>

Hello Chris:

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
chris at lavin-llc.com
Sent: Wednesday, September 02, 2009 11:28 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] OT - Dark Fiber

I was curious to know if there are different ways to go about purchasing
dark fiber. If you have Site A and Site B only a few miles apart and
you're 
happy to provide the light, how do you get the fiber? Not expecting to
obtain right-of-way/permits/ditch digger. Do you lease (meaning paying a
MRC) or 
is it 'purchased' (meaning a NRC)?

Thanks,
-chris

--------------------

You could do a couple of things:

1) If there aren't any providers between buildings you could look for
existing conduit or pole rights if you have above-ground electrical
service.
2) If there are dark fiber providers:
   - You could get a standard NRC/MRC deal (as someone said already)
   - You could get a long-term IRU (Indefensible Right of Use) where you
pay a lot up front but very little MRC and you have sole use of the
fibers for a period of years.

Regards,

Mike

From tomas at soitron.com  Wed Sep  2 16:35:37 2009
From: tomas at soitron.com (Daniska, Tomas)
Date: Wed, 2 Sep 2009 22:35:37 +0200
Subject: [c-nsp] Management stuff in VRFs
In-Reply-To: <1251920188.2923.4.camel@abehat.net.rm.dk>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>
Message-ID: <6B43981C32F8464CB24CEE209DA32BD3025171B7@kenya.tronet.as>


> I'm a little curious since there have been so many threads about
> running
> management stuff in VRFs. I've until now considered VRFs something for
> customers only; management is in the global table.
> 
> Is management from a VRF to be considered "best practice"?

Telcos are doing something similar for ages - they are deploying
physically separate networks for management and they know very well why
they do so. IP equipment is just getting there, e.g. Nexus has dedicated
management ports which are forced into a management VRF.
 
> What are the benefits from using a VRF for this?

It's kind of mimicking separate control and forwarding planes. Though
the separation is virtual, it's still better than none.
 
> I assume everyone uses infrastructure ACLs so the VRF thingy shouldn't
> be any more "secure". Or should it?

First, ACL is reactive mechanism, management separation is proactive.
You prevent unwanted stuff from entering your management network even
before you can filter it. Second, you isolate problems - think your IGP
not working because of whatever reason (attack, misconfiguration...),
but you still can ssh your box via the (quasi) out-of-band management,
which you don't touch at the same time, and repair the network. Etc.
Many more. ;)

--

deejay
 

__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4389
(20090902) __________

Tuto spravu preveril ESET NOD32 Antivirus.

http://www.eset.sk
 

From jim at jamesberwick.com  Wed Sep  2 15:55:08 2009
From: jim at jamesberwick.com (James Berwick)
Date: Wed, 02 Sep 2009 15:55:08 -0400
Subject: [c-nsp] ATM packet loss
In-Reply-To: <alpine.DEB.1.10.0909022058410.20521@uplift.swm.pp.se>
References: <4A9EB3FF.9070805@jamesberwick.com>
	<alpine.DEB.1.10.0909022058410.20521@uplift.swm.pp.se>
Message-ID: <4A9ECD9C.5060309@jamesberwick.com>

Mikael Abrahamsson wrote:
> On Wed, 2 Sep 2009, James Berwick wrote:
>
>> works fine.  Pinging a customer on our OC3 with any packet larger 
>> than 576 bytes intermittently fails.
>>
>> This is the ATM OC3 config:
>> interface ATM1/1/0
>> mac-address 0000.0c71.1148
>> bandwidth 155000
>> no ip address
>> load-interval 30
>> atm ilmi-keepalive
>> end
>
> First thing I'd try here would be to configure some ubr value on the 
> OC3, set it to 120 megabit/s or something like that. If that helps, 
> increase until you get close to wirespeed and see if the problem 
> creeps up the higher the UBR. The behaviour you're seeing is alike to 
> what I've seen when there is a cell policer dropping cells somewhere.
>
I rebuilt a PVC on the circuit to ubr 149760 (full linespeed of our OC3) 
and observed the same results.  Continuous pings of 576 bytes work 
flawlessly.  577 byte pings show between 1% and 2% packet loss.  We 
don't maintain the ATM network between us and our customers.  The LEC 
that does has gone to two of our customer's facilities and put an ATM 
test kit on the DS3 and tested sending 45mbit/sec of cells across that 
particular customer's PVC.  We've then looped the OC3 in the router with 
loopback line on the ATM1/1/0 interface and they saw 45mbit/sec worth of 
cells returned.

I'm not sure where to look for a cell policer.  This OC3 comes from the 
LEC into our 7500 series and we don't have any QoS or rate limiting on 
the ATM interface itself or any of the PVCs.

I'm not sure if this is helpful information or not but if we use 
something like speedtest.net from a customer's network we end up with 
results like 5mbit down, 30mbit up.  It seems like the throttling is 
taking place in only one direction, but we aren't (intentionally) doing 
it on our router and the LEC who handles the ATM cloud swears up and 
down they aren't doing anything that would cap throughput and none of 
the switches between us and the customer are oversubscribed.

I just tested now by kicking off enough ping -f x.x.x.x -s 548's (Ping 
flood with 576 byte packets) to push 20mbit/sec worth of ICMP traffic 
across a PVC with 0% packet loss, while the same test with a 1000 byte 
ping fails miserably.  I'm at a loss as to why either our router, our 
LEC's ATM network (which according to them is doing no policing at all 
of our UBR traffic), or a dozen of our customer's Cisco routers have all 
suddenly decided that packets over 576 bytes need to get dropped on the 
floor randomly.

This is what our interface looks like:
ATM1/1/0 is up, line protocol is up
  Hardware is cyBus ENHANCED ATM PA
  MTU 4470 bytes, sub MTU 4470, BW 155000 Kbit, DLY 80 usec,
     reliability 255/255, txload 48/255, rxload 13/255
  Encapsulation ATM, loopback not set
  Encapsulation(s): AAL5
  4095 maximum active VCs, 32 current VCCs
  VC Auto Creation Disabled.
  VC idle disconnect time: 300 seconds
  0 carrier transitions
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 1d05h
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 60
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 8191000 bits/sec, 3544 packets/sec
  30 second output rate 29327000 bits/sec, 4090 packets/sec
     289263860 packets input, 803308614 bytes, 0 no buffer
     Received 254286 broadcasts, 0 runts, 6 giants, 0 throttles
     7 input errors, 1 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     326860666 packets output, 1743804746 bytes, 0 underruns
     60 packets late drop, 86107 bytes late drop
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out

Interface ATM1/1/0:
AAL enabled:  AAL5  , Maximum VCs: 4095, Current VCCs: 32

Maximum Transmit Channels: 0
Max. Datagram Size: 4528
PLIM Type: SONET - 155000Kbps, TX clocking: LINE
Cell-payload scrambling: ON
sts-stream scrambling: ON
178409785 input, 327045383 output, 29153365 IN fast, 109018418 OUT fast, 
0 out dropVBR-NRT : 672
 Avail bw = 149088
Config. is ACTIVE

From rsm at fast-serv.com  Wed Sep  2 16:51:05 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Wed, 2 Sep 2009 16:51:05 -0400
Subject: [c-nsp] BGP multihop between two sites
In-Reply-To: <6B43981C32F8464CB24CEE209DA32BD3025171B7@kenya.tronet.as>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>
	<6B43981C32F8464CB24CEE209DA32BD3025171B7@kenya.tronet.as>
Message-ID: <20090902204250.M69344@fast-serv.com>

We have two sites advertising unique subnets via the same AS.  Since the
subnets originate from the same AS they apparently get dropped from the tables
at each site.  

Each site has at least 3 upstreams taking full tables from each with a 6509.  

Site a has a single border router with dual supervisors.

Site b actually has dual border routers.  Each router handles different
upstreams and trades routes via iBGP.

So I think I need to set up a multihop session between the sites.  

Right now, traffic between sites is taking the floating default route and
causes issues between sites when one of our BGP peers is down for whatever reason.

What are the things to look out for when setting up this multihop?  Are there
gotcha's to deal with given one site has dual active routers?

Can anyone provide me or point me to an example multihop config to work from?

--
Randy


From mksmith at adhost.com  Wed Sep  2 17:08:25 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Wed, 2 Sep 2009 14:08:25 -0700
Subject: [c-nsp] BGP multihop between two sites
In-Reply-To: <20090902204250.M69344@fast-serv.com>
References: <1251920188.2923.4.camel@abehat.net.rm.dk><6B43981C32F8464CB24CEE209DA32BD3025171B7@kenya.tronet.as>
	<20090902204250.M69344@fast-serv.com>
Message-ID: <17838240D9A5544AAA5FF95F8D52031606934800@ad-exh01.adhost.lan>



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Randy McAnally
Sent: Wednesday, September 02, 2009 1:51 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] BGP multihop between two sites

We have two sites advertising unique subnets via the same AS.  Since the
subnets originate from the same AS they apparently get dropped from the
tables
at each site.  

Each site has at least 3 upstreams taking full tables from each with a
6509.  

Site a has a single border router with dual supervisors.

Site b actually has dual border routers.  Each router handles different
upstreams and trades routes via iBGP.

So I think I need to set up a multihop session between the sites.  

Right now, traffic between sites is taking the floating default route
and
causes issues between sites when one of our BGP peers is down for
whatever reason.

What are the things to look out for when setting up this multihop?  Are
there
gotcha's to deal with given one site has dual active routers?

Can anyone provide me or point me to an example multihop config to work
from?

--
Randy

-----

You could also use the 'neighbor x.x.x.x allowas-in' which will let you
see your own AS being advertised incoming.

Regards,

Mike

--
Michael K. Smith - CISSP, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)



From gsgranados at comcast.net  Wed Sep  2 17:34:55 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Wed, 2 Sep 2009 14:34:55 -0700
Subject: [c-nsp] BGP multihop between two sites
References: <1251920188.2923.4.camel@abehat.net.rm.dk><6B43981C32F8464CB24CEE209DA32BD3025171B7@kenya.tronet.as>
	<20090902204250.M69344@fast-serv.com>
Message-ID: <023801ca2c15$3bff6890$2208120a@am.thmulti.com>

You can set your neighbor statements to allow learning from the same AS so 
the routes won't be dropped.

Another good way to do this is to set up a GRE tunnel between the sites and 
connect your devices using the attached /30 addresses.

----- Original Message ----- 
From: "Randy McAnally" <rsm at fast-serv.com>
To: <cisco-nsp at puck.nether.net>
Sent: Wednesday, September 02, 2009 1:51 PM
Subject: [c-nsp] BGP multihop between two sites


> We have two sites advertising unique subnets via the same AS.  Since the
> subnets originate from the same AS they apparently get dropped from the 
> tables
> at each site.
>
> Each site has at least 3 upstreams taking full tables from each with a 
> 6509.
>
> Site a has a single border router with dual supervisors.
>
> Site b actually has dual border routers.  Each router handles different
> upstreams and trades routes via iBGP.
>
> So I think I need to set up a multihop session between the sites.
>
> Right now, traffic between sites is taking the floating default route and
> causes issues between sites when one of our BGP peers is down for whatever 
> reason.
>
> What are the things to look out for when setting up this multihop?  Are 
> there
> gotcha's to deal with given one site has dual active routers?
>
> Can anyone provide me or point me to an example multihop config to work 
> from?
>
> --
> Randy
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From peter at rathlev.dk  Wed Sep  2 18:05:06 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Thu, 03 Sep 2009 00:05:06 +0200
Subject: [c-nsp] Geographically dispersed ASA failover?
In-Reply-To: <79AF0C3901752A49881FE4CB31F7AA40016ECC39@abn-borg2.NETABN.LOCAL>
References: <79AF0C3901752A49881FE4CB31F7AA40016ECC39@abn-borg2.NETABN.LOCAL>
Message-ID: <1251929106.2923.11.camel@abehat.net.rm.dk>

On Wed, 2009-09-02 at 11:38 -0500, Michael Malitsky wrote:
> Does anyone know if the ASA failover feature supports a setup where the
> ASAs are in geographically different locations?  Specifically, I have
> two data centers about 30 miles apart, connected by a 50Mb metro
> ethernet link with latency under 10ms.  

I think you'll be fine. We're currently running a pair of ASAs in
failover with ~40 km LoS between them (RTT ~0.7 ms) without the
slightest problems at all. It traverses a mix of 1Gig and 10Gig links.

Regards,
Peter



From asturluismi at gmail.com  Wed Sep  2 18:23:44 2009
From: asturluismi at gmail.com (luismi)
Date: Thu, 03 Sep 2009 00:23:44 +0200
Subject: [c-nsp] Management stuff in VRFs
In-Reply-To: <1251920188.2923.4.camel@abehat.net.rm.dk>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>
Message-ID: <1251930224.8038.0.camel@dsba-ipso>

I have everything splitted.


From clinton at scripty.com  Wed Sep  2 17:59:02 2009
From: clinton at scripty.com (Clinton Work)
Date: Wed, 02 Sep 2009 15:59:02 -0600
Subject: [c-nsp] Management stuff in VRFs
In-Reply-To: <1251920188.2923.4.camel@abehat.net.rm.dk>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>
Message-ID: <4A9EEAA6.30106@scripty.com>


A management VRF is attractive from best practice perspective, but full 
management support like using the global routing table is lacking in 
Cisco IOS.   I have enhancement CSCsu22476 open to support selecting the 
syslog source interface when using VRF aware syslog (IOS 12.4T).  While 
not always practical for full Internet routes, I would recommend using 
the global routing table for mgmt and putting all the customer traffic 
in a VRF.  There are also many Cisco IOS features which only work in the 
global routing table making a management VRF more attractive. 


Peter Rathlev wrote:
> I'm a little curious since there have been so many threads about running
> management stuff in VRFs. I've until now considered VRFs something for
> customers only; management is in the global table.
>
> Is management from a VRF to be considered "best practice"?
>
> What are the benefits from using a VRF for this?
>
> I assume everyone uses infrastructure ACLs so the VRF thingy shouldn't
> be any more "secure". Or should it?
>   


From illcritikz at gmail.com  Wed Sep  2 18:59:59 2009
From: illcritikz at gmail.com (Ben Steele)
Date: Thu, 3 Sep 2009 08:59:59 +1000
Subject: [c-nsp] do i *need* DFCs on the 6500?
In-Reply-To: <20090902111616.GA6588@lboro.ac.uk>
References: <20090902111616.GA6588@lboro.ac.uk>
Message-ID: <4422cf660909021559q24279309v826c36b3ef78b2a7@mail.gmail.com>

Unless you are hitting a cam limit on any of your resources on your SUP(very
possible if you are exporting netflow) OR you are congesting the crossbar
fabric(sh fabric util) which is pretty unlikely when you are talking a 24G
linecard on a 40G fabric connection then you probably won't see any
difference putting a DFC on a 6724

Remember these chassis are a hardware only based forwarding solution, so all
your doing with a DFC is moving cam/asic resources off the sup, so in
regards to your specific questions unless you have filled all your QoS
queues on the sup you are going to see nothing more on the DFC, also the sup
does (from memory) up to 100-200m pps in ipv6, I don't believe for a moment
you are even remotely close to this, and the global ipv6 routing table is no
where near the cam limit for that either, by the way is your SUP an XL? does
the DFC's on the 10G's match the sup or have they fallen back to the lowest
common configuration?

"...or could it be that DFC's are only really useful to a particular
deployment
and I just *think* i need them?  ;-)" - I think you might be on the money
here.

If you give us the current utilization of your cam resources(from the sup)
and the 6724 linecard throughput and what its functions
are(netflow/qos/mac/acls etc) then we can tell you for sure.

Ben


On Wed, Sep 2, 2009 at 9:16 PM, Alan Buxey <A.L.M.Buxey at lboro.ac.uk> wrote:

> hi,
>
> okay, from the background of I know what the DFC is and how it
> operates etc... i know I want them - however, I need to justify
> the upgrade/part cost to sort out a couple of 6500's.  in some of
> our 6500's, the 10G blades have DFCs already...but several 6724's dont
> (they just have CFC). ...as i said, I want them, but need to get
> some management/funding buy-in - and they dont want the 'what it
> does' information - they want some hard and fast facts that Cisco dont
> sem to want to tell me ..... so, the question is
>
> 1) is there any way of showing the sup720 strain/utilisation...particularly
> is there a way of showing DFC usage on the blades where we have them?
>
> 2) it offloads IPv6 and QoS - we're into both of those (and more so over
> the
> next year) - any particular insights into QoS performance/issues without
> DFC ? any throughput figures for IPv6 ?
>
> (i know that with CFC we're limited to the backplane (32mpps?) and we get ~
> 48mpps
> per blade with DFC)
>
> ...or could it be that DFC's are only really useful to a particular
> deployment
> and I just *think* i need them?  ;-)
>
> alan
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From John.Herbert at ins.com  Wed Sep  2 18:50:02 2009
From: John.Herbert at ins.com (John.Herbert at ins.com)
Date: Wed, 2 Sep 2009 17:50:02 -0500
Subject: [c-nsp] BGP multihop between two sites
In-Reply-To: <20090902204250.M69344@fast-serv.com>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>
	<6B43981C32F8464CB24CEE209DA32BD3025171B7@kenya.tronet.as>,
	<20090902204250.M69344@fast-serv.com>
Message-ID: <3BA4D8A8-4A4D-483A-9B80-9A1524F46062@mimectl>

Randy,

By no means an answer to all your questions, but there may be some useful info in this thread regarding routing over the internet between the same ASN:

http://www.gossamer-threads.com/lists/nanog/users/115689?#115689

I'm not quite clear on the floating default? What is it floating "over"? If you are receiving a default in BGP, then are you / can you receive it from multiple providers for resiliency? And if so, under what circumstances is the floating static ever active in your routing tables?

John.

________________________________
From: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net] On Behalf Of Randy McAnally [rsm at fast-serv.com]
Sent: Wednesday, September 02, 2009 16:51
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] BGP multihop between two sites

We have two sites advertising unique subnets via the same AS.  Since the
subnets originate from the same AS they apparently get dropped from the tables
at each site.

Each site has at least 3 upstreams taking full tables from each with a 6509.

Site a has a single border router with dual supervisors.

Site b actually has dual border routers.  Each router handles different
upstreams and trades routes via iBGP.

So I think I need to set up a multihop session between the sites.

Right now, traffic between sites is taking the floating default route and
causes issues between sites when one of our BGP peers is down for whatever reason.

What are the things to look out for when setting up this multihop?  Are there
gotcha's to deal with given one site has dual active routers?

Can anyone provide me or point me to an example multihop config to work from?

--
Randy

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From John.Herbert at ins.com  Wed Sep  2 18:58:55 2009
From: John.Herbert at ins.com (John.Herbert at ins.com)
Date: Wed, 2 Sep 2009 17:58:55 -0500
Subject: [c-nsp] Management stuff in VRFs
In-Reply-To: <1251920188.2923.4.camel@abehat.net.rm.dk>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>
Message-ID: <A2D22135-6CF3-49B5-9067-978EEAC06B58@mimectl>

Personally, my recommendation is that if you can afford to have a separate management network, do it. It would also be nice if more network devices had truly isolated management ports such that bearer/management traffic never have to cross paths, share routing tables, and so forth.

Various IOS versions also do not have syntax to tell the router to send syslog / snmp trap / tacacs via the management VRF, defaulting instead to the global routing table. This can be worked around with some effort, but it's an annoyance.

Plus if you have instability in your network environment for any reason, you don't want to be reliant on that unstable network to get access to the routers so you can fix it - you're working on the very transport you're relying on for connectivity.

That said, it can be done with some careful planning, and especially if you have out of band console access as a 'back door' in case of bad connectivity issues, you may have a reasonable compromise without having the expense of parallel management infrastructure.

John.

________________________________
From: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Rathlev [peter at rathlev.dk]
Sent: Wednesday, September 02, 2009 15:36
To: cisco-nsp
Subject: [c-nsp] Management stuff in VRFs

I'm a little curious since there have been so many threads about running
management stuff in VRFs. I've until now considered VRFs something for
customers only; management is in the global table.

Is management from a VRF to be considered "best practice"?

What are the benefits from using a VRF for this?

I assume everyone uses infrastructure ACLs so the VRF thingy shouldn't
be any more "secure". Or should it?

Regards,
Peter




_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From cordmacleod at gmail.com  Wed Sep  2 19:50:55 2009
From: cordmacleod at gmail.com (Cord MacLeod)
Date: Wed, 2 Sep 2009 16:50:55 -0700
Subject: [c-nsp] BGP multihop between two sites
In-Reply-To: <20090902204250.M69344@fast-serv.com>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>
	<6B43981C32F8464CB24CEE209DA32BD3025171B7@kenya.tronet.as>
	<20090902204250.M69344@fast-serv.com>
Message-ID: <9F541963-A681-4819-9CE4-39A07C627AE9@gmail.com>

On Sep 2, 2009, at 1:51 PM, Randy McAnally wrote:

> We have two sites advertising unique subnets via the same AS.  Since  
> the
> subnets originate from the same AS they apparently get dropped from  
> the tables
> at each site.
>
> Each site has at least 3 upstreams taking full tables from each with  
> a 6509.
>
> Site a has a single border router with dual supervisors.
>
> Site b actually has dual border routers.  Each router handles  
> different
> upstreams and trades routes via iBGP.
>
> So I think I need to set up a multihop session between the sites.
>
> Right now, traffic between sites is taking the floating default  
> route and
> causes issues between sites when one of our BGP peers is down for  
> whatever reason.
>
> What are the things to look out for when setting up this multihop?   
> Are there
> gotcha's to deal with given one site has dual active routers?

Multihop BGP is not a good idea in this example.  You'll want to use  
something like neighbor x.x.x.x allowas-in on your eBGP sessions.   
However, you'll also want to setup a BGP filter to deny your own  
sourced prefixes to prevent loops/flapping.  Meaning, when you allow  
prefixes from site A into site B, setup a BGP filter on site B denying  
B's prefixes and vice versa.

From andy.saykao at staff.netspace.net.au  Wed Sep  2 20:07:00 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Thu, 3 Sep 2009 10:07:00 +1000
Subject: [c-nsp] Is Cisco SLB vrf aware?
Message-ID: <56F211C5E3F24F47B103EA1B253822BE044AABC0@vic-cr-ex1.staff.netspace.net.au>

Does anyone know if Cisco SLB is vrf aware???
Can't seem to find much information on it which is leading me to believe
it's not vrf aware.
 
Trying to implement this on Cisco 7301 running 12.2(18)S13.
 
Thanks.
 
Andy

This email and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed. 
Please notify the sender immediately by email if you have received this 
email by mistake and delete this email from your system. 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 organisation. 
Finally, the recipient should check this email and any attachments for 
the presence of viruses. The organisation accepts no liability for any 
damage caused by any virus transmitted by this email.


From Skeeve at eintellego.net  Wed Sep  2 19:20:16 2009
From: Skeeve at eintellego.net (Skeeve Stevens)
Date: Thu, 3 Sep 2009 09:20:16 +1000
Subject: [c-nsp] 6509, Sup2 VRF's
Message-ID: <292AF25E62B8894C921B893B53A19D973957E7F38F@BUSINESSEX.business.ad>

Hey all,

In my Googleness I've found some old (2006 and back) comments about SUP2's and not being able to do VRF-Lite on many interfaces.

Research has indicated SOME interfaces are supported, loopbacks for example, but I can find no definitive of which ones are supported.

Or... in the past 3 years has there been any IOS releases which may have updated it.

I saw a brief post which wasn't complete in which someone used a line card to loop the Ethernet back or somesuch to get SVI's into a VRF.... but I couldn't find anymore.

Essentially VLAN's or SVI's is what I want to get into a VRF, and it would be nice for layer 3 interfaces as well... but I will take what I can get.  Does anyone have any creative ideas on how one might accomplish this?  i.e. using one of the maybe supported WAN cards (is there a list?) in which we could accomplish the same result.

Thanks all (and to Ian Cox's earlier comments)

--
Skeeve Stevens, CEO/Technical Director
eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego.net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
www.linkedin.com/in/skeeve ; facebook.com/eintellego
--
NOC, NOC, who's there?

Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced.


From rsm at fast-serv.com  Wed Sep  2 21:10:02 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Wed, 2 Sep 2009 21:10:02 -0400
Subject: [c-nsp] BGP multihop between two sites
In-Reply-To: <3BA4D8A8-4A4D-483A-9B80-9A1524F46062@mimectl>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>
	<6B43981C32F8464CB24CEE209DA32BD3025171B7@kenya.tronet.as>,
	<20090902204250.M69344@fast-serv.com>
	<3BA4D8A8-4A4D-483A-9B80-9A1524F46062@mimectl>
Message-ID: <20090903010632.M90344@fast-serv.com>

> I'm not quite clear on the floating default? What is it floating "over"? If you are receiving a default in BGP,
> then are you / can you receive it from multiple providers for resiliency? And if so, under what circumstances
>? is the floating static ever active in your routing tables?

It's a high distance static default route in place, to keep packets flowing in case of an eBGP malfunction.? In this case, it was routing packets between locations because the prefixes were not in the routing tables.? This was not discovered until the provider the default pointed went down.

-- 
Randy

 

From John.Herbert at ins.com  Wed Sep  2 22:42:22 2009
From: John.Herbert at ins.com (John.Herbert at ins.com)
Date: Wed, 2 Sep 2009 21:42:22 -0500
Subject: [c-nsp] BGP multihop between two sites
In-Reply-To: <20090903010632.M90344@fast-serv.com>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>
	<6B43981C32F8464CB24CEE209DA32BD3025171B7@kenya.tronet.as>,
	<20090902204250.M69344@fast-serv.com>
	<3BA4D8A8-4A4D-483A-9B80-9A1524F46062@mimectl>,
	<20090903010632.M90344@fast-serv.com>
Message-ID: <15407A77-34F6-4B8D-AB41-DE8CBBE3E991@mimectl>

Ah I think I see. Assuming you have no default route learned via eBGP then (given 3 full routing tables, that's probably a fair assumption), the question becomes whether you can intelligently maintain a floating static default based on reachability to the next-hop IP, or if it's better to implement some kind of BGP peering between the two sites.

One possibility might be to consider a conditional static default route - use "ip sla" to test next hop reachability of a provider's router, then use the track command to monitor and apply to a floating default route (and of course, you can do this for more than one provider and provide a predetermined sequence of alternate default routes)

I am not personally a fan of iBGP "raw" over a public network (and that's what it would be since the ASNs are the same on both ends), as most of the protection features in IOS are focused on eBGP. GRE tunnel works, though there may be caveats depending on MTU/fragmentation issues and hardware switching support. Maintaining those BGP peers of course assumes that the remote IP in each case is known in one of the active eBGP sessions at all time. Probably a reasonable assumption if you're using provider-owned IPs to peer; maybe less so if you're using IPs that fall within your own larger block.

I may be misunderstanding something about your particular topology, so my apologies if so.

John.

________________________________
From: Randy McAnally [rsm at fast-serv.com]
Sent: Wednesday, September 02, 2009 21:10
To: Herbert, John; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] BGP multihop between two sites

> I'm not quite clear on the floating default? What is it floating "over"? If you are receiving a default in BGP,
> then are you / can you receive it from multiple providers for resiliency? And if so, under what circumstances
>  is the floating static ever active in your routing tables?

It's a high distance static default route in place, to keep packets flowing in case of an eBGP malfunction.  In this case, it was routing packets between locations because the prefixes were not in the routing tables.  This was not discovered until the provider the default pointed went down.

--
Randy <http://www.fastserv.com/>



From arievayner at gmail.com  Thu Sep  3 00:17:27 2009
From: arievayner at gmail.com (Arie Vayner)
Date: Thu, 3 Sep 2009 07:17:27 +0300
Subject: [c-nsp] 6509, Sup2 VRF's
In-Reply-To: <292AF25E62B8894C921B893B53A19D973957E7F38F@BUSINESSEX.business.ad>
References: <AcosI+5ibtGE/7j9REWxqpS7kJbvvw==>
	<292AF25E62B8894C921B893B53A19D973957E7F38F@BUSINESSEX.business.ad>
Message-ID: <20b13c6b0909022117o26c705eey968adc1f41525a31@mail.gmail.com>

Skeeve,

You could try and get an OSM module (it is become obsolete as the Sup2...)
This card would allow you to implement not just VRF-Lite but also full blown
MPLS/VPN.

You would have to use an external trunk from the "6500" to the "OSM", and
bridge any VLAN you want to use inside a VRF to the OSM, which would perform
all the L3 functionality for that VLAN.

Arie

On Thu, Sep 3, 2009 at 2:20 AM, Skeeve Stevens <Skeeve at eintellego.net>wrote:

> Hey all,
>
> In my Googleness I've found some old (2006 and back) comments about SUP2's
> and not being able to do VRF-Lite on many interfaces.
>
> Research has indicated SOME interfaces are supported, loopbacks for
> example, but I can find no definitive of which ones are supported.
>
> Or... in the past 3 years has there been any IOS releases which may have
> updated it.
>
> I saw a brief post which wasn't complete in which someone used a line card
> to loop the Ethernet back or somesuch to get SVI's into a VRF.... but I
> couldn't find anymore.
>
> Essentially VLAN's or SVI's is what I want to get into a VRF, and it would
> be nice for layer 3 interfaces as well... but I will take what I can get.
>  Does anyone have any creative ideas on how one might accomplish this?  i.e.
> using one of the maybe supported WAN cards (is there a list?) in which we
> could accomplish the same result.
>
> Thanks all (and to Ian Cox's earlier comments)
>
> --
> Skeeve Stevens, CEO/Technical Director
> eintellego Pty Ltd - The Networking Specialists
> skeeve at eintellego.net / www.eintellego.net
> Phone: 1300 753 383, Fax: (+612) 8572 9954
> Cell +61 (0)414 753 383 / skype://skeeve
> www.linkedin.com/in/skeeve ; facebook.com/eintellego
> --
> NOC, NOC, who's there?
>
> Disclaimer: Limits of Liability and Disclaimer: This message is for the
> named person's use only. It may contain sensitive and private proprietary or
> legally privileged information. You must not, directly or indirectly, use,
> disclose, distribute, print, or copy any part of this message if you are not
> the intended recipient. eintellego Pty Ltd and each legal entity in the
> Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail
> communications through its networks.  Any views expressed in this message
> are those of the individual sender, except where the message states
> otherwise and the sender is authorised to state them to be the views of any
> such entity. Any reference to costs, fee quotations, contractual
> transactions and variations to contract terms is subject to separate
> confirmation in writing signed by an authorised representative of
> eintellego. Whilst all efforts are made to safeguard inbound and outbound
> e-mails, we cannot guarantee that attachments are!
>  virus-free or compatible with your systems and do not accept any liability
> in respect of viruses or computer problems experienced.
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From swmike at swm.pp.se  Thu Sep  3 00:56:37 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Thu, 3 Sep 2009 06:56:37 +0200 (CEST)
Subject: [c-nsp] ATM packet loss
In-Reply-To: <4A9ECD9C.5060309@jamesberwick.com>
References: <4A9EB3FF.9070805@jamesberwick.com>
	<alpine.DEB.1.10.0909022058410.20521@uplift.swm.pp.se>
	<4A9ECD9C.5060309@jamesberwick.com>
Message-ID: <alpine.DEB.1.10.0909030654590.20521@uplift.swm.pp.se>

On Wed, 2 Sep 2009, James Berwick wrote:

>> First thing I'd try here would be to configure some ubr value on the OC3, 
>> set it to 120 megabit/s or something like that. If that helps, increase 
>> until you get close to wirespeed and see if the problem creeps up the 
>> higher the UBR. The behaviour you're seeing is alike to what I've seen when 
>> there is a cell policer dropping cells somewhere.
>> 
> I rebuilt a PVC on the circuit to ubr 149760 (full linespeed of our OC3) and

To re-iterate.

Set it to 120 megs and try again. If there is still a problem, lower it 
and see if it helps.

Also, what Cisco hardware are you using exactly? PA-A3-OC3* cards in 
VIP2-50:s or are you using better gear?

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se

From vedlabs at gmail.com  Thu Sep  3 02:14:01 2009
From: vedlabs at gmail.com (Ved Labs)
Date: Thu, 3 Sep 2009 11:44:01 +0530
Subject: [c-nsp] dampening for VPNv4
In-Reply-To: <4422cf660909010247y324ab799vae31e03402d6cf3a@mail.gmail.com>
References: <7db92dcc0908290435s2c9b32eerc64f076eea1f17a2@mail.gmail.com>
	<7db92dcc0908312241w6951ead8x77efa9b781484414@mail.gmail.com>
	<4422cf660909010247y324ab799vae31e03402d6cf3a@mail.gmail.com>
Message-ID: <7db92dcc0909022314y33ad8ecch791e606fed8c8e3e@mail.gmail.com>

Thanks Ben for the directions .

I enabled the bgp dampening for VPNv4 address-family .
It helped to some extent to see the flapped statistics from the CE .
I blocked one of the /16 network , which was flapping at a higher rate ,
coming from CE.

Still i do not see significant improvement in the CPU utilisation due to
"BGP router" process.

i can see some changes in prefixes recieved for the VPNv4 route reflector
session.
and there are around 20000 prefixes coming from the VPVv4 RR.
How do i find the culprit

The router is 7206 with NPE-G1 .
Could there be a memory or hardware limilitation also or some bug.

Thanks,
Ved.

From jim at jamesberwick.com  Thu Sep  3 02:50:44 2009
From: jim at jamesberwick.com (James Berwick)
Date: Thu, 03 Sep 2009 02:50:44 -0400
Subject: [c-nsp] ATM packet loss
In-Reply-To: <alpine.DEB.1.10.0909030654590.20521@uplift.swm.pp.se>
References: <4A9EB3FF.9070805@jamesberwick.com>
	<alpine.DEB.1.10.0909022058410.20521@uplift.swm.pp.se>
	<4A9ECD9C.5060309@jamesberwick.com>
	<alpine.DEB.1.10.0909030654590.20521@uplift.swm.pp.se>
Message-ID: <4A9F6744.2000000@jamesberwick.com>

Mikael Abrahamsson wrote:
> On Wed, 2 Sep 2009, James Berwick wrote:
>
> To re-iterate.
>
> Set it to 120 megs and try again. If there is still a problem, lower 
> it and see if it helps.
>
> Also, what Cisco hardware are you using exactly? PA-A3-OC3* cards in 
> VIP2-50:s or are you using better gear?
>
Ok, to test I just built a 120 meg ubr pvc.  It performed identically to 
the 45 meg PVC we've been testing with.  I also built several other 
speeds (30, 45, 60, 90) and they all performed identically, packet loss 
for packets over 576 bytes and download speeds in the 1-5mbit range. 

The hardware is a Cisco 7507 chassis with an RSP16 with 1GB of RAM.  The 
VIP is a VIP-480 with 256 megs of RAM.  The only port adapter in the VIP 
is a PA-A3-OC3-SMI.  The RSP CPU load averages 20% and show proc cpu 
hist does not show any time period that the max CPU broke 50%.  The RSP 
has approximately 850 MB of free RAM.

if-con'd into the VIP, it has about 190 megs of free RAM and shows an 
average utilization between 0% and 10% over the past 72 hours, no maxes 
higher than 20%.

Our MRTG graphs show that September of last year this same hardware was 
pushing over 100mbit/sec on our ATM OC3. 

This chassis only does ATM traffic.  We have a Covad ATM DS3 in a 
VIP2-50 in slot 0.  This DS3 is working fine.  We have a Verizon OC3 in 
a VIP-480 in Slot 1.  This is our problem OC3.  We have VIP-480s in 
slots 4 and 6 also terminating Verizon ATM DS3s, these are also working 
fine.  We also have a VIP-480 in slot 5 with a gigabit adapter to uplink 
the router to the rest of our network.

I just realized something that may (or may not be) helpful. 

We use ATM mostly for schools and other educational institutes, but we 
also receive residential and business DSL traffic over our ATM 
circuits.  We've got around 400 DSL customers on this OC3 who are online 
right now, with a mixture of PPPoE and statically bridged DSL users and 
I'm not seeing anything wrong with any of their connections, ie, no 
packet loss, no performance issues.

Please excuse me if I missed something or typed it very poorly, I've 
been working on this problem for about 18 hours now and I'm fried.  
Thanks again for the suggestions!

From rdobbins at arbor.net  Thu Sep  3 03:18:21 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Thu, 3 Sep 2009 14:18:21 +0700
Subject: [c-nsp] Management stuff in VRFs
In-Reply-To: <1251920188.2923.4.camel@abehat.net.rm.dk>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>
Message-ID: <8E7A89C7-56A8-43E2-B5BA-A66EB8A47F3C@arbor.net>


On Sep 3, 2009, at 2:36 AM, Peter Rathlev wrote:

> Is management from a VRF to be considered "best practice"?


Increasingly, for many purposes, yes.  Note that you can specify a VRF  
as the destination for NDE NetFlow telemetry, for example.

Also, Cisco's Nexus 7000-series IDC switches allow the control and  
management planes of the switch to be separated into four Virtual  
Device Contexts, or VDCs.  For the first time, a piece of general- 
purpose hardware can safely be used to carry both production and OOB  
management/Data Communications Network (DCN) management-type traffic  
across the same physical hardware.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

Sorry, sometimes I mistake your existential crises for technical
insights.

			-- xkcd #625


From jdurand at renater.fr  Thu Sep  3 04:17:02 2009
From: jdurand at renater.fr (Jerome Durand)
Date: Thu, 03 Sep 2009 10:17:02 +0200
Subject: [c-nsp] Management stuff in VRFs
In-Reply-To: <1251920188.2923.4.camel@abehat.net.rm.dk>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>
Message-ID: <4A9F7B7E.9030202@renater.fr>

We went in that direction in our latest deployment and discovered also 
that many pieces were missing in IOS and IOS-XR to have full management 
in a dedicated VRF for all our devices.

At this stage we have the VRF but not all management goes there... so 
there is more complexity and network is no more secure... I must admit 
IOS-XR gives us more troubles as more management features are missing in 
VRF's.

Maybe for a pure IOS network there could be an added value (?)

Regards,
Jerome





Peter Rathlev a ?crit :
> I'm a little curious since there have been so many threads about running
> management stuff in VRFs. I've until now considered VRFs something for
> customers only; management is in the global table.
> 
> Is management from a VRF to be considered "best practice"?
> 
> What are the benefits from using a VRF for this?
> 
> I assume everyone uses infrastructure ACLs so the VRF thingy shouldn't
> be any more "secure". Or should it?
> 
> Regards,
> Peter
> 
> 
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
-------------------------------------------------------------
Jerome Durand

Responsable des services aux usagers
Services operations & support manager

             R?seau National de T?l?communications
      pour la Technologie, l'Enseignement et la Recherche

Tel:    +33 (0) 1 53 94 20 40  |  GIP RENATER
Fax:    +33 (0) 1 53 94 20 41  |  c/o ENSAM
E-mail: jdurand at renater.fr     |  151 Boulevard de l'H?pital
http://www.renater.fr          |  75013 PARIS
--------------------------------------------------------------


From eng_mssk at hotmail.com  Thu Sep  3 05:03:29 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Thu, 3 Sep 2009 12:03:29 +0300
Subject: [c-nsp] IDS
Message-ID: <BLU102-W243DD98E9CE677E2983988FAEF0@phx.gbl>


hey all

if i have in a data center a 2 firewall and 1 IDS system
what will be the optimal or best topology to make 


_________________________________________________________________
Show them the way! Add maps and directions to your party invites. 
http://www.microsoft.com/windows/windowslive/products/events.aspx

From p.mayers at imperial.ac.uk  Thu Sep  3 05:35:29 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Thu, 03 Sep 2009 10:35:29 +0100
Subject: [c-nsp] do i *need* DFCs on the 6500?
In-Reply-To: <4422cf660909021559q24279309v826c36b3ef78b2a7@mail.gmail.com>
References: <20090902111616.GA6588@lboro.ac.uk>
	<4422cf660909021559q24279309v826c36b3ef78b2a7@mail.gmail.com>
Message-ID: <4A9F8DE1.8030001@imperial.ac.uk>

Ben Steele wrote:
> Unless you are hitting a cam limit on any of your resources on your SUP(very
> possible if you are exporting netflow) OR you are congesting the crossbar
> fabric(sh fabric util) which is pretty unlikely when you are talking a 24G
> linecard on a 40G fabric connection then you probably won't see any
> difference putting a DFC on a 6724

That depends completely on what other cards are on the box, what their 
offered forwarding load is, and whether they have DFCs.

> 
> Remember these chassis are a hardware only based forwarding solution, so all
> your doing with a DFC is moving cam/asic resources off the sup, so in
> regards to your specific questions unless you have filled all your QoS
> queues on the sup you are going to see nothing more on the DFC, also the sup
> does (from memory) up to 100-200m pps in ipv6, I don't believe for a moment

No. The PFC3 does 30Mpps IPv4 (and 15Mpps IPv6 I think). A DFC3 does 
48Mpps IPv4 (and 24Mpps IPv6).

http://www.cisco.com/en/US/products/hw/switches/ps708/products_qanda_item09186a00809a7673.shtml

A fully-populated and fully-DFCed 6509 does 400Mpps IPv4 or 200Mpps IPv6 
(well, actually 192Mpps - 24x8 linecards). In this configuration, the 
PFC does very little.

It's worth noting that a 6724 doing 64-bytes packets on all ports offers 
~47Mpps forwarding load - well in excess of the PFC capacity. A chassis 
full of 6724s without DFCs at 10% load with 64-bytes packets also 
exceeds the PFC capacity.

Obviously these are worst-case numbers but illustrative of the problems 
you can get yourself into if you don't capacity plan well.

It's worth noting that some linecards have different (i.e. more 
flexible) rx & tx queueing methods with a DFC versus the CFC.

There's also the bus-stall issues, which go away (supposedly) with a DFC 
installed since they're not connected to the bus.

> you are even remotely close to this, and the global ipv6 routing table is no
> where near the cam limit for that either, by the way is your SUP an XL? does
> the DFC's on the 10G's match the sup or have they fallen back to the lowest
> common configuration?

I'm not sure why you mention CAM limits, but it's worth noting that DFCs 
do not help with FIB CAM at all, since they hold a copy of the PFC FIB.

Personally we get DFCs on everything since we're using plain -3B (or -3C 
not) rather than XL, and the cost of the DFC is a pretty minimal 
percentage of the linecard for the future-proofing.

We've also seen software bugs manifest on CFC cards in the past; this 
implies to me that Cisco "prefer" DFC chassis. Similarly some of the new 
linecards e.g. 6708/6716 are DFC-only. I suspect that will be the case 
going forward.

From illcritikz at gmail.com  Thu Sep  3 07:42:01 2009
From: illcritikz at gmail.com (Ben Steele)
Date: Thu, 3 Sep 2009 21:42:01 +1000
Subject: [c-nsp] do i *need* DFCs on the 6500?
In-Reply-To: <4A9F8DE1.8030001@imperial.ac.uk>
References: <20090902111616.GA6588@lboro.ac.uk>
	<4422cf660909021559q24279309v826c36b3ef78b2a7@mail.gmail.com>
	<4A9F8DE1.8030001@imperial.ac.uk>
Message-ID: <4422cf660909030442g798fb607xd81e0588bf33c79@mail.gmail.com>

On Thu, Sep 3, 2009 at 7:35 PM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:

> Ben Steele wrote:
>
>> Unless you are hitting a cam limit on any of your resources on your
>> SUP(very
>> possible if you are exporting netflow) OR you are congesting the crossbar
>> fabric(sh fabric util) which is pretty unlikely when you are talking a 24G
>> linecard on a 40G fabric connection then you probably won't see any
>> difference putting a DFC on a 6724
>>
>
> That depends completely on what other cards are on the box, what their
> offered forwarding load is, and whether they have DFCs.


Hence asking him to check these values, or at least implying from
that sentence that he should :)


>
>
>
>> Remember these chassis are a hardware only based forwarding solution, so
>> all
>> your doing with a DFC is moving cam/asic resources off the sup, so in
>> regards to your specific questions unless you have filled all your QoS
>> queues on the sup you are going to see nothing more on the DFC, also the
>> sup
>> does (from memory) up to 100-200m pps in ipv6, I don't believe for a
>> moment
>>
>
> No. The PFC3 does 30Mpps IPv4 (and 15Mpps IPv6 I think). A DFC3 does 48Mpps
> IPv4 (and 24Mpps IPv6).
>
>
> http://www.cisco.com/en/US/products/hw/switches/ps708/products_qanda_item09186a00809a7673.shtml
>
> A fully-populated and fully-DFCed 6509 does 400Mpps IPv4 or 200Mpps IPv6
> (well, actually 192Mpps - 24x8 linecards). In this configuration, the PFC
> does very little.
>

Ok my bad, my memory was for the full chassis not the individual PFC, should
read docco next time before posting! i'm still quite certain our OP isn't
doing 15Mpps of IPv6, if he is then he must be the IPv6 hub of the world.


>
> It's worth noting that a 6724 doing 64-bytes packets on all ports offers
> ~47Mpps forwarding load - well in excess of the PFC capacity. A chassis full
> of 6724s without DFCs at 10% load with 64-bytes packets also exceeds the PFC
> capacity.
>
> Obviously these are worst-case numbers but illustrative of the problems you
> can get yourself into if you don't capacity plan well.
>

I think it's safe to say our OP is no where near these limits or he would
definitely know about it, in fact I doubt anyone in the world has hit 47Mpps
on any 6500 linecard(in a real world situation, no labs), please if someone
has feel free to let me know about it.

But yes capacity planning is very important.


>
> It's worth noting that some linecards have different (i.e. more flexible)
> rx & tx queueing methods with a DFC versus the CFC.
>

True but keep in mind the OP already has some DFC enabled linecards so I
would assume he is familiar with what QoS he can and can't schedule on the
CFC vs DFC, his particular comment related to performance and offloading of
QoS - not features, the same goes for different line cards in general
though, like the 4 and 8 port 10Gb line cards, totally different buffering
capabilities, you need to choose your line card wisely, our OP already has
his in place.


> There's also the bus-stall issues, which go away (supposedly) with a DFC
> installed since they're not connected to the bus.


Interesting.. i'll take your word for that, can't say i've seen much in the
way of bus stalls when working with them(at least in recent times) except
the standard OIR one, i'll assume this is an actual performance impacting
stall you are referring to, does this apply even if the chassis is in
compact mode?


>
>
>  you are even remotely close to this, and the global ipv6 routing table is
>> no
>> where near the cam limit for that either, by the way is your SUP an XL?
>> does
>> the DFC's on the 10G's match the sup or have they fallen back to the
>> lowest
>> common configuration?
>>
>
> I'm not sure why you mention CAM limits, but it's worth noting that DFCs do
> not help with FIB CAM at all, since they hold a copy of the PFC FIB.
>

Yeah my ipv6 FIB CAM statement was pretty irrelevant and was more me typing
then realising i'm not sure if we are even talking XL or not here, wasn't
the greatest sentence.


>
> Personally we get DFCs on everything since we're using plain -3B (or -3C
> not) rather than XL, and the cost of the DFC is a pretty minimal percentage
> of the linecard for the future-proofing.
>

No doubt it's better to have a DFC than not have a DFC but some companies
are tight with money and justifying just a few thousand for something you
don't *really* need can be hard, while non XL upgrade might seem trivial I
think you'll find to upgrade a 6724 from stock to a 3CXL DFC is around the
price of the actual line card itself, that said neither of us know what PFC
the OP is running :)


>
> We've also seen software bugs manifest on CFC cards in the past; this
> implies to me that Cisco "prefer" DFC chassis. Similarly some of the new
> linecards e.g. 6708/6716 are DFC-only. I suspect that will be the case going
> forward.
>

Well from a performance point of view it makes sense, but it all equals $$
and companies are being stingier than ever with the GFC in everyones head.

I still get the feeling the OP doesn't need the DFC, generally you know if
you need one as it's not something you think ooo that might be nice to have
i'll take 5! you are normally saying I need X because Y doesn't work or Y
will stop working in the near future, maybe the OP has a valid reason for
needing it, I just didn't see it and don't want him(or his company) to buy
something they don't need.

From maddison at lightbound.net  Thu Sep  3 09:19:53 2009
From: maddison at lightbound.net (Matt Addison)
Date: Thu, 3 Sep 2009 09:19:53 -0400
Subject: [c-nsp] do i *need* DFCs on the 6500?
In-Reply-To: <4A9F8DE1.8030001@imperial.ac.uk>
References: <20090902111616.GA6588@lboro.ac.uk><4422cf660909021559q24279309v826c36b3ef78b2a7@mail.gmail.com>
	<4A9F8DE1.8030001@imperial.ac.uk>
Message-ID: <DC5B236BCDAABA4C87C86F962FFCC541028CEA53@exchange.iquest.org>

> There's also the bus-stall issues, which go away (supposedly) with a
DFC
> installed since they're not connected to the bus.

The chassis bus stall is done by 3 physical pins in the slot, so DFC or
not you still stall and potentially reboot the chassis while
inserting/removing a card- however DFC enabled line cards are not
subject to the packet loss associated with a bus stall [1].

~Matt

1:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_qanda_ite
m09186a00809a7673.shtml#qa4

From rsm at fast-serv.com  Thu Sep  3 09:37:59 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Thu, 3 Sep 2009 09:37:59 -0400
Subject: [c-nsp] BGP multihop between two sites
In-Reply-To: <15407A77-34F6-4B8D-AB41-DE8CBBE3E991@mimectl>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>
	<6B43981C32F8464CB24CEE209DA32BD3025171B7@kenya.tronet.as>,
	<20090902204250.M69344@fast-serv.com>
	<3BA4D8A8-4A4D-483A-9B80-9A1524F46062@mimectl>,
	<20090903010632.M90344@fast-serv.com>
	<15407A77-34F6-4B8D-AB41-DE8CBBE3E991@mimectl>
Message-ID: <20090903133422.M65689@fast-serv.com>

No, I think you understand it perfectly.

The goal is to have 'stateful knowledge' of my own eBGP routes, using the simplest most resilient and cross-platform compatible method.

What would be the caveats of the neigbor x.x.x.x allowas-in?? It seems too easy, there HAS to be a catch!? :)

Do I need to change my inbound filters?? Right now I am not filtering inbound routes from the directly connected Tier1's.

-- 
Randy

---------- Original Message -----------
From: <John.Herbert at ins.com> 
To: <rsm at fast-serv.com>, <cisco-nsp at puck.nether.net> 
Sent: Wed, 2 Sep 2009 21:42:22 -0500 
Subject: RE: [c-nsp] BGP multihop between two sites

> Ah I think I see.?Assuming you have no default route learned via eBGP then (given 3 full routing tables, that's probably a fair assumption), the question becomes whether you can intelligently maintain a floating static default based on reachability to the next-hop IP, or if it's better to implement some kind of BGP peering between the two sites.
> ?
> One possibility might be to consider a conditional static default route - use "ip sla" to test next hop reachability of a provider's router, then use the track command to monitor and apply to?a floating?default route (and of course, you can do this for more than one provider and provide a predetermined sequence of alternate default routes)
> ?
> I am not personally a fan of iBGP "raw" over a public network (and that's what it would be since the ASNs are the same on both ends),?as most of the protection features?in IOS are focused on eBGP.?GRE tunnel works, though there may be caveats depending on MTU/fragmentation issues and hardware switching support. Maintaining those BGP peers of course assumes that the remote IP in each case is known in one of the active eBGP sessions at all time. Probably a reasonable assumption if you're using provider-owned IPs to peer; maybe less so if you're using IPs that fall within your own larger block.
> ?
> I may be misunderstanding something about your particular topology, so my apologies if so.
> ?
> John.
> ?
> 
-----------------------------------------------------------------------
From: Randy McAnally [rsm at fast-serv.com]
> Sent: Wednesday, September 02, 2009 21:10
> To: Herbert, John; cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] BGP multihop between two sites
> 
> 
> > I'm not quite clear on the floating default? What is it floating "over"? If you are receiving a default in BGP, 
> > then are you / can you receive it from multiple providers for resiliency? And if so, under what circumstances 
> >? is the floating static ever active in your routing tables? 
> 
> It's a high distance static default route in place, to keep packets flowing in case of an eBGP malfunction.? In this case, it was routing packets between locations because the prefixes were not in the routing tables.? This was not discovered until the provider the default pointed went down. 
> 
> -- 
> Randy 
> 
> 
> 
------- End of Original Message -------
 

From tomas at soitron.com  Thu Sep  3 09:54:09 2009
From: tomas at soitron.com (Daniska, Tomas)
Date: Thu, 3 Sep 2009 15:54:09 +0200
Subject: [c-nsp] BGP multihop between two sites
In-Reply-To: <20090903133422.M65689@fast-serv.com>
References: <1251920188.2923.4.camel@abehat.net.rm.dk><6B43981C32F8464CB24CEE209DA32BD3025171B7@kenya.tronet.as>,
	<20090902204250.M69344@fast-serv.com><3BA4D8A8-4A4D-483A-9B80-9A1524F46062@mimectl>,
	<20090903010632.M90344@fast-serv.com><15407A77-34F6-4B8D-AB41-DE8CBBE3E991@mimectl>
	<20090903133422.M65689@fast-serv.com>
Message-ID: <6B43981C32F8464CB24CEE209DA32BD30251733F@kenya.tronet.as>



> 
> What would be the caveats of the neigbor x.x.x.x allowas-in?? It seems
> too easy, there HAS to be a catch!? :)
> 

The catch is that EBGP has admin distance of 20 by default so the prefixes received via EBGP would override anything dynamic in your AS. But that might not be an issue for you as that's what you eventually want to achieve. 


--

deejay
 

__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4391 (20090903) __________

Tuto spravu preveril ESET NOD32 Antivirus.

http://www.eset.sk
 

From geoff at pendery.net  Thu Sep  3 10:00:56 2009
From: geoff at pendery.net (Geoffrey Pendery)
Date: Thu, 3 Sep 2009 09:00:56 -0500
Subject: [c-nsp] do i *need* DFCs on the 6500?
In-Reply-To: <4422cf660909021559q24279309v826c36b3ef78b2a7@mail.gmail.com>
References: <20090902111616.GA6588@lboro.ac.uk>
	<4422cf660909021559q24279309v826c36b3ef78b2a7@mail.gmail.com>
Message-ID: <d6966e4b0909030700m73372f1ai70293d448b93b40e@mail.gmail.com>

"congesting the crossbar fabric(sh fabric util) which is pretty
unlikely when you are talking a 24G linecard on a 40G fabric
connection"

Just a nitpick or two - the 6724 only has one channel of fabric, so
it's a 24G linecard with a 20G fabric connection, thus a slight
oversubscription.  If you're extremely rigorous about line-rate, leave
four of those ports unused.

But the DFC issue is more about Mpps than Mbps.  As Phil pointed out,
you could run them well under their line-rate, but with small packets,
and overwhelm the forwarding capacity of the PFC.


-Geoff


On Wed, Sep 2, 2009 at 5:59 PM, Ben Steele<illcritikz at gmail.com> wrote:
> Unless you are hitting a cam limit on any of your resources on your SUP(very
> possible if you are exporting netflow) OR you are congesting the crossbar
> fabric(sh fabric util) which is pretty unlikely when you are talking a 24G
> linecard on a 40G fabric connection then you probably won't see any
> difference putting a DFC on a 6724
>
> Remember these chassis are a hardware only based forwarding solution, so all
> your doing with a DFC is moving cam/asic resources off the sup, so in
> regards to your specific questions unless you have filled all your QoS
> queues on the sup you are going to see nothing more on the DFC, also the sup
> does (from memory) up to 100-200m pps in ipv6, I don't believe for a moment
> you are even remotely close to this, and the global ipv6 routing table is no
> where near the cam limit for that either, by the way is your SUP an XL? does
> the DFC's on the 10G's match the sup or have they fallen back to the lowest
> common configuration?
>
> "...or could it be that DFC's are only really useful to a particular
> deployment
> and I just *think* i need them? ?;-)" - I think you might be on the money
> here.
>
> If you give us the current utilization of your cam resources(from the sup)
> and the 6724 linecard throughput and what its functions
> are(netflow/qos/mac/acls etc) then we can tell you for sure.
>
> Ben
>
>
> On Wed, Sep 2, 2009 at 9:16 PM, Alan Buxey <A.L.M.Buxey at lboro.ac.uk> wrote:
>
>> hi,
>>
>> okay, from the background of I know what the DFC is and how it
>> operates etc... i know I want them - however, I need to justify
>> the upgrade/part cost to sort out a couple of 6500's. ?in some of
>> our 6500's, the 10G blades have DFCs already...but several 6724's dont
>> (they just have CFC). ...as i said, I want them, but need to get
>> some management/funding buy-in - and they dont want the 'what it
>> does' information - they want some hard and fast facts that Cisco dont
>> sem to want to tell me ..... so, the question is
>>
>> 1) is there any way of showing the sup720 strain/utilisation...particularly
>> is there a way of showing DFC usage on the blades where we have them?
>>
>> 2) it offloads IPv6 and QoS - we're into both of those (and more so over
>> the
>> next year) - any particular insights into QoS performance/issues without
>> DFC ? any throughput figures for IPv6 ?
>>
>> (i know that with CFC we're limited to the backplane (32mpps?) and we get ~
>> 48mpps
>> per blade with DFC)
>>
>> ...or could it be that DFC's are only really useful to a particular
>> deployment
>> and I just *think* i need them? ?;-)
>>
>> alan
>> _______________________________________________
>> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From almog.purepeak at gmail.com  Thu Sep  3 10:04:51 2009
From: almog.purepeak at gmail.com (almog ohayon)
Date: Thu, 3 Sep 2009 17:04:51 +0300
Subject: [c-nsp] CIsco ASA processes
Message-ID: <3b53747c0909030704y34c6eeedm6a4284585ba3784c@mail.gmail.com>

Hello Everyone,Does anyone knows what is a Dispatch Unit process in Cisco
ASA 5510 ??
And also to check the attached file and understand why my CPU usage has peak
of 10 - 20 % in 5 sec intervals.

thanks,
--
Almog.
-------------- next part --------------
Cisco-ASA-CLT/act# sh processes     
    
    PC       SP       STATE       Runtime    SBASE     Stack Process
Lwe 08051bac d450bac4 09b7aeb4          0 d4509bb0 7920/8192 block_diag
Mrd 081727e4 d453c464 09b7a7fc   15010044 d451c5f0 124300/131072 Dispatch Unit
Mwe 0835e1f5 d4541614 09b7a5ec          0 d453f820 7496/8192 CF OIR
Mwe 08963190 d454382c 09aac950          0 d4541948 7872/8192 lina_int
Mwe 08064bc5 d45b235c 09b7a5ec          4 d45b04b8 4448/8192 Reload Control Thread
Mwe 08069626 d45bd274 09b7c718        582 d45b96c0 12688/16384 aaa
Mwe 08092416 d45c408c 09b7c774          0 d45c0198 15712/16384 CMGR Server Process
Mwe 08092925 d45c6154 09b7a5ec          0 d45c42c0 7760/8192 CMGR Timer Process
Lwe 08171342 d45d078c 09b877a4          0 d45ce888 7376/8192 dbgtrace
Msi 083e650c d45d8d7c 09b7a5ec      13257 d45d6e68 7808/8192 557mcfix
Msi 083e632e d45daea4 09b7a5ec          3 d45d8f90 7776/8192 557statspoll
Mwe 08b5480d d480105c 09b7a5ec          1 d45f69e8 7136/8192 netfs_thread_init
Mwe 09144be5 d4604e2c 09b7a5ec          0 d4602fa8 7640/8192 Chunk Manager
Msi 087fabee d461020c 09b7a5ec      22610 d460e318 7316/8192 PIX Garbage Collector
Mwe 087ee244 d4619e6c 09a9dcac          1 d4617f68 6184/8192 IP Address Assign
Mwe 089adaf6 d47ab864 09adf078          0 d47a9960 7904/8192 QoS Support Module
Mwe 0886b62f d47ad9c4 09a9ed50          0 d47abac0 7904/8192 Client Update Task
Lwe 091845b8 d47b023c 09b7a5ec     175392 d47ae3a8 7696/8192 Checkheaps
Mwe 089b0d45 d47b646c 09b7a5ec          0 d47b4808 6624/8192 Quack process
Mwe 08a04632 d47ba7a4 09b7a5ec       1847 d47b6930 15504/16384 Session Manager
Mwe 08b03785 d47c5204 d50fffd0          9 d47c17b0 14296/16384 uauth
Mwe 08aa5795 d47c77dc 09aebdc0          0 d47c58d8 7376/8192 Uauth_Proxy
Msp 08adc06c d47cf574 09b7a5ec       1017 d47cd660 7552/8192 SSL
Mwe 08b01be6 d47d165c 09af18c4          0 d47cf788 7240/8192 SMTP
Mwe 08af6f79 d47d3624 09af1848    5744443 d47d18b0 3080/8192 Logger
Mwe 08af359e d47d586c 09b7a5ec          0 d47d39d8 7344/8192 Thread Logger
Mwe 08cd1c42 d47e40d4 09b242e8          0 d47e21f0 7040/8192 vpnlb_thread
Mwe 0823344d d47eaa7c 09b7a5ec          0 d47e8bf8 7640/8192 TLS Proxy Inspector
Msi 08a1d073 d48730d4 09b7a5ec      20871 d48711d0 7792/8192 emweb/cifs_timer
Mwe 0860ca27 d48b5b2c 09a948ac          0 d48b3c38 7520/8192 netfs_mount_handler
Msi 084c2788 d45ca3e4 09b7a5ec      92385 d45c8510 7168/8192 arp_timer
Mwe 084cbc7c d45d6bf4 09b9af68          0 d45d4d40 7824/8192 arp_forward_thread
Mwe 0852fb65 d45dcf3c 09b9fd60          3 d45db0b8 7808/8192 Lic TMR
Mwe 08b06da1 d4602d74 09af1b40          0 d4600e80 7776/8192 tcp_fast
Mwe 08b09f90 d4b3171c 09af1b40          0 d4b2f838 7760/8192 tcp_slow
Mwe 08b33bf9 d4b3f40c 09af9a48          0 d4b3d518 7872/8192 udp_timer
Mwe 080e6cb8 d45e7fdc 09b7a5ec          0 d45e6148 7760/8192 CTCP Timer process
Mwe 08c82503 d45faa2c 09b7a5ec          0 d45f8bb8 7728/8192 L2TP data daemon
Mwe 08c832d3 d45fcb14 09b7a5ec          0 d45fac90 7744/8192 L2TP mgmt daemon
Mwe 08c6f3db d4e9adcc 09b1e224       4212 d4e96f18 16048/16384 ppp_timer_thread
Msi 08cd20a7 d4e9ce14 09b7a5ec      28436 d4e9af40 7744/8192 vpnlb_timer_thread
Mwe 080fc9d7 d45cc4dc d45fec50         13 d45ca638 3320/8192 IPsec message handler
Msi 0810ecfc d47c98c4 09b7a5ec     446843 d47c7a00 6328/8192 CTM message handler
Mwe 088c5a1a d45ce5d4 09b7a5ec          4 d45cc760 5852/8192 NAT security-level reconfiguration
Mwe 089daea8 d5085294 09b7a5ec          0 d50833f0 7776/8192 ICMP event handler
Mwe 087550b3 d508940c 09b7a5ec       5422 d5085568 14520/16384 IP Background
Mwe 08169957 d50f0e7c 09a726f4        235 d50d0fb8 122936/131072 tmatch compile thread
Mwe 088f1a05 d51c75bc 09b7a5ec          0 d51c3708 15880/16384 Crypto PKI RECV
Mwe 088f44fa d51cb6c4 09b7a5ec          0 d51c7830 15848/16384 Crypto CA
Lsi 0880aad8 d5203024 09b7a5ec        279 d5201110 7808/8192 uauth_urlb clean
Lwe 087f3f2f d541381c 09b7a5ec      80809 d54119a8 4228/8192 pm_timer_thread
Mwe 084556c5 d5415bf4 09b7a5ec      29445 d5413d60 7624/8192 IKE Timekeeper
Mwe 084492eb d541b0ac 09a8fcb4      14416 d54174d8 10408/16384 IKE Daemon
Mwe 08ab90da d541eccc 09af04d4          0 d541cde8 7872/8192 RADIUS Proxy Event Daemon
Mwe 08a8717b d5420c64 d47d8c60         39 d541eec0 7032/8192 RADIUS Proxy Listener
Mwe 08ab7cd7 d5422e2c 09b7a5ec          0 d5420f98 7760/8192 RADIUS Proxy Time Keeper
Mwe 084b3a3c d5425bdc 09b9aee8          0 d5423da8 7008/8192 Integrity FW Task
Mwe 08186d8b d546066c 096595dc          0 d5440e68 124996/131072 ci/console
Mwe 08391745 d5462e24 09b7a5ec       2417 d5460f90 3672/8192 fover_thread
Mwe 08c572b5 d5464f4c 09d20850       3912 d54630b8 6192/8192 lu_ctl
Msi 0882c89c d5466ee4 09b7a5ec     186241 d54651e0 5992/8192 update_cpu_usage
Msi 08827d31 d547129c 09b7a5ec     558886 d546f468 5992/8192 NIC status poll
Mwe 08381bcc d47e60bc 09b8e700      68218 d47e4318 4016/8192 fover_rx
Mwe 0837e400 d47b246c 09b8f094      33363 d47b05b8 5652/8192 fover_tx
Mwe 0837d50b d45f6784 09b9b5c8      97670 d45f48a0 4456/8192 fover_ip
Mwe 08391b41 d54894ec 09b8f0a8       1813 d5485808 9968/16384 fover_rep
Mwe 0838a51d d54913e4 09b8f0b0      94193 d5489830 22100/32768 fover_parse
Mwe 0836d52d d54936fc 09b8e1d8    7734565 d5491858 5480/8192 fover_ifc_test
Mwe 08370b85 d5495714 09b7a5ec     789535 d5493880 3656/8192 fover_health_monitoring_thread
Mwe 083a3f10 d5499964 09b7a5ec      10480 d5497ad0 5388/8192 ha_trans_ctl_tx
Mwe 083a3f10 d54ac9b4 09b7a5ec       7988 d54aab20 5748/8192 ha_trans_data_tx
Mwe 0839b517 d54ae9ec 09b7a5ec         21 d54acb48 5344/8192 fover_FSM_thread
Mwe 08c56cdb d54b11a4 09b9b028       3742 d54af2a0 5936/8192 lu_rx
Lwe 08c56c0c d54b31dc 09d20700          2 d54b12c8 6208/8192 lu_dynamic_sync
Mwe 08a4e793 d54bc444 09ae3900         59 d54ba550 3112/8192 SNMP Notify Thread
Mwe 08b5480d d553878c 09b7a5ec        135 d54bc578 24816/32768 rtcli async executor process
Mwe 084bdd86 d56a1134 09b9b634     183650 d569d260 12948/16384 IP Thread
Mwe 084c442e d56a327c 09b9afe8     253107 d56a1388 3672/8192 ARP Thread
Mwe 083ebe80 d57287ec 09b9b620       3835 d5726998 4908/8192 icmp_thread
Mwe 08b34b16 d572a854 09b7a5ec      14016 d57289c0 7656/8192 udp_thread
Mwe 08b0c06e d572c73c 09b9b63c          0 d572a9e8 7472/8192 tcp_thread
Mwe 08b15643 d572e8a4 09b7a5ec       1084 d572ca10 5680/8192 npshim_thread
Mwe 08a8717b d5757e7c d45d09c0         36 d57560c8 7368/8192 EAPoUDP-sock
Mwe 081acd75 d5759d54 09b7a5ec          0 d57581f0 6840/8192 EAPoUDP
Mwe 08b33ca8 d57605c4 d4b3d1a4     495936 d575eda0 2100/8192 snmp
Mwe 08b16758 d584be24 d5843f80          0 d584a170 6760/8192 listen/telnet
Mwe 08b16758 d5850bec d58453c0       1689 d584ef38 6760/8192 listen/ssh
Mwe 08cb260d d59e13ec 09b24008          8 d59d94f8 28228/32768 vpnfol_thread_msg
Msi 08cb85b2 d59e39bc 09b7a5ec      45194 d59e1ad8 7164/8192 vpnfol_thread_timer
Mwe 08cb6ab2 d59e5f4c 09b24180          0 d59e40b8 7016/8192 vpnfol_thread_sync
Msi 08cb813c d59e858c 09b7a5ec     127066 d59e6698 7776/8192 vpnfol_thread_unsent
Mwe 084afd88 d47dfe14 09b7a5ec          0 d47ddf80 7760/8192 Integrity Fw Timer Thread
Msi 0860cafc d546b27c 09b7a5ec       1203 d5469398 7752/8192 netfs_vnode_reclaim
Mwe 08acd4fb d546ea54 09b7a5ec         14 d546cbc0 4104/8192 ssh/timer
M*  08ac72dc d0b2491c 09b7a7fc         50 d61193f8 25552/32768 ssh
Mwe 08a8717b d603051c d61c2160         21 d602e778 7352/8192 IKE Receiver
Mwe 08b5480d d5a7938c 09b7a5ec        563 d6054b98 4796/8192 Unicorn Admin Thread
Mwe 086ede53 d5f7981c 09b7a5ec      26455 d5f77988 3480/8192 NTP
Lwe 0885d943 d5f4fa0c 09b7a5ec         18 d5f4dba8 7648/8192 vPif_stats_cleaner
Mwe 08b16758 d5f1bc7c d5750b28        249 d5f19f88 5648/8192 tacplus_get
Mwe 089cefe9 d5f679cc 09ae0058     365738 d5f65ad8  824/8192 tacplus_snd
 -     -        -         -    5568869652    -         -     scheduler
 -     -        -         -    5619348425    -         -     total elapsed
 
 
Cisco-ASA-CLT/act# sh processes internals | exc 0.

     Invoked      Giveups  Max_Runtime  Process
     5486735            4        6.328  PIX Garbage Collector
         494          492        8.865  uauth
     2421411           16        1.354  IKE Daemon
      692565            6        1.598  fover_thread
     9543545      2945996       39.565  fover_parse
          16            9       68.732  rtcli async executor process
          23            2        1.282  vpnfol_thread_msg
        2432         2319        3.333  ssh
        1835          917        3.365  vPif_stats_cleaner

From Jonathan.Brashear at hq.speakeasy.net  Thu Sep  3 10:15:38 2009
From: Jonathan.Brashear at hq.speakeasy.net (Jonathan Brashear)
Date: Thu, 3 Sep 2009 07:15:38 -0700
Subject: [c-nsp] CIsco ASA processes
In-Reply-To: <3b53747c0909030704y34c6eeedm6a4284585ba3784c@mail.gmail.com>
References: <3b53747c0909030704y34c6eeedm6a4284585ba3784c@mail.gmail.com>
Message-ID: <725755F5E728EE4086DAAF1A54DACF4F0E5BB33F73@sea5exbe1.speakeasy.hq>

Do you have threat detection stats turned on?  That's an easy way to add 10-20% to your CPU usage. 


Network Engineer, JNCIS-M
> 214-981-1954 (office) 
> 214-642-4075 (cell)
> jbrashear at hq.speakeasy.net 
http://www.speakeasy.net
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of almog ohayon
Sent: Thursday, September 03, 2009 9:05 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] CIsco ASA processes

Hello Everyone,Does anyone knows what is a Dispatch Unit process in Cisco
ASA 5510 ??
And also to check the attached file and understand why my CPU usage has peak
of 10 - 20 % in 5 sec intervals.

thanks,
--
Almog.

From ayourtch at cisco.com  Thu Sep  3 11:25:14 2009
From: ayourtch at cisco.com (Andrew Yourtchenko)
Date: Thu, 3 Sep 2009 17:25:14 +0200 (CEST)
Subject: [c-nsp] CIsco ASA processes
In-Reply-To: <3b53747c0909030704y34c6eeedm6a4284585ba3784c@mail.gmail.com>
References: <3b53747c0909030704y34c6eeedm6a4284585ba3784c@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0909031721230.3441@zippy.stdio.be>

Hi,

On Thu, 3 Sep 2009, almog ohayon wrote:

> Hello Everyone,Does anyone knows what is a Dispatch Unit process in Cisco
> ASA 5510 ??

low-level packet forwarding. Don't worry about the high Runtime number 
there, if that is the underlying question :)

> And also to check the attached file and understand why my CPU usage has peak
> of 10 - 20 % in 5 sec intervals.

take two "show proc" and look at the difference of runtimes (except the 
"dispatch unit" processes).

Otherwise the values are since the last restart. But if your utilisation 
was steady over all the time, then periodic high volume of logging might 
have something to do with it.

thanks,
andrew

From gsgranados at comcast.net  Thu Sep  3 13:41:07 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Thu, 3 Sep 2009 10:41:07 -0700
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
References: <000501ca2b64$54ea36c0$0202fea9@am.thmulti.com><6E21B2BDEF6E714EA0B5BA8D5D0E1401248E269EB4@zy-ex1.zyedge.local>
	<00ea01ca2bec$cc3c98c0$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347A7@ad-exh01.adhost.lan>
	<012501ca2bf4$ec98c550$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347B1@ad-exh01.adhost.lan>
	<013501ca2bf7$74241a40$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347B8@ad-exh01.adhost.lan>
Message-ID: <018601ca2cbd$bc8f7600$2208120a@am.thmulti.com>

Hi Mike and others, still no love.  I wanted to confirm I made the NAT 
entries properly.  I used the example on Cisco.com for the ASA and l2l + 
clients as an example.


Here are the important bits

global (outside) 1 206.x.x.234
nat (inside) 0 access-list nonat
nat (inside) 1 0.0.0.0 0.0.0.0

And nonat acl

access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 192.168.122.0 255.255.255.192 
10.18.14.0 255.255.255.0
access-list nonat extended permit ip 157.254.0.0 255.255.0.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip host 216.x.x.196 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.18.0.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.18.1.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.18.2.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.18.3.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.18.4.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.18.5.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.18.6.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.18.7.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.18.8.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.18.9.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.18.10.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.18.15.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.15.0.0 255.255.0.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.32.0.0 255.240.0.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 192.168.255.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 172.30.0.0 255.255.0.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.18.11.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.18.12.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.18.13.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.18.16.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.1.192.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.1.224.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.1.225.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.1.226.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.1.227.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.1.228.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.1.229.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.1.230.0 255.255.255.0 10.18.14.0 
255.255.255.0
access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 192.168.122.0 255.255.255.192 
10.18.15.0 255.255.255.192
access-list nonat extended permit ip 157.254.0.0 255.255.0.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip host 216.x.x.196 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.18.0.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.18.1.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.18.2.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.18.3.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.18.4.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.18.5.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.18.6.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.18.7.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.18.8.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.18.9.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.18.10.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.18.15.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.15.0.0 255.255.0.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.32.0.0 255.240.0.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 192.168.255.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 172.30.0.0 255.255.0.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.18.11.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.18.12.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.18.13.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.18.16.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.1.192.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.1.224.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.1.225.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.1.226.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.1.227.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.1.228.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.1.229.0 255.255.255.0 10.18.15.0 
255.255.255.192
access-list nonat extended permit ip 10.1.230.0 255.255.255.0 10.18.15.0 
255.255.255.192


Two points here.  I defined each as individual /24's to prevent the 
inclusion of the 10.18.14.0/24 range and so we can add or delete easily 
because we're presently migrating a bit from one 10.x range to another. 
Also, I doubled up the listings 1 for the destination of 10.18.14.0/24 which 
is the clients and 10.18.15.0/26 which is a far end site.  Not sure if I'm 
heading in the other direction.  The error I received while trying to bring 
up the tunnel is unchanged.  "removing peer failed, no match!"

I did grab some debug output from the Pix side here's the important bit

crypto_isakmp_process_block:src:vpnc, dest:208.x.x.98 spt:500 dpt:500
ISAKMP: reserved not zero on payload 5!
ISAKMP: malformed payload

I assume malformed payload means I have something set incorrectly during the 
negotiation phase.

Any pointers would be appreciated.  I will grab more debug data per the 
other post but this is what I've tried so far.

Thanks
Scott

----- Original Message ----- 
From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
To: "Scott Granados" <gsgranados at comcast.net>
Sent: Wednesday, September 02, 2009 11:03 AM
Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel


Correct.  But you can have multiple statements in your ACL.

Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.15.0
255.255.255.192
Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.15.192
255.255.255.192
Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.14.0
255.255.255.0

And so on.

Mike

--
Michael K. Smith - CISSP, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


-----Original Message-----
From: Scott Granados [mailto:gsgranados at comcast.net]
Sent: Wednesday, September 02, 2009 11:02 AM
To: Michael K. Smith - Adhost; Ryan West; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi Michael, thanks but one thing I'm not clear on.

Suppose I have destinations of
10.18.15.0/26 10.18.15.192/26 10.18.14.0/24 etc.
In other words my possible destinations can be different.  If I use your

example what happens if traffic has the proper source but a destination
of
10.18.15.192/26 or if traffic is destined to a client on 10.18.14.0/24?
It
won't match the ACL correct?


----- Original Message ----- 
From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
To: "Scott Granados" <gsgranados at comcast.net>; "Ryan West"
<rwest at zyedge.com>; <cisco-nsp at puck.nether.net>
Sent: Wednesday, September 02, 2009 10:47 AM
Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel


Hi Scott:

No, if you use the no-nat below, *all* traffic from 10.18.0.0/24 will
not be NAT'd, regardless of the destination.  What you want is:

Access-list nonat permit ip 10.18.0.0 255.255.255.0 <remote subnet>
<remote mask>

In looking at your post below, I think that would be:

Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.15.0
255.255.255.192

I should note that the mask on the remote side for the 10.18.0.0 subnet
is a /20, not a /24.

Regards,

Mike

--
Michael K. Smith - CISSP, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


-----Original Message-----
From: Scott Granados [mailto:gsgranados at comcast.net]
Sent: Wednesday, September 02, 2009 10:44 AM
To: Michael K. Smith - Adhost; Ryan West; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi Mike, to follow up on this, I do have existing clients working now.
For
the nonat rule would I create a sepperate ACL for each target or would a

basic acl like I use for the split tunneling do the trick?

either
access-list ny-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.0

255.255.255.192
or would
access-list nonat standard permit 10.18.0.0 255.255.255.0

I have several different targets so how would one define that or is the
standard ACL enough?

Thanks for the pointers!
Scott

----- Original Message ----- 
From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
To: "Scott Granados" <gsgranados at comcast.net>; "Ryan West"
<rwest at zyedge.com>; <cisco-nsp at puck.nether.net>
Sent: Wednesday, September 02, 2009 10:33 AM
Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel


Hello Ryan:

Without the no-nat on the ASA side it will try to NAT the traffic before
putting it down the tunnel.  So, you're remove side is looking for the
10. Addresses, but it's going to see traffic coming from the static
outside, NAT'd address.  Thus, the tunnel won't come up because your
proposals don't match.

Mike

--
Michael K. Smith - CISSP, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Wednesday, September 02, 2009 9:45 AM
To: Ryan West; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi, so right now my Pix in the field is pointing at a VPN 3000 so I
can't
take that path down until after hours but I will to capture the debug
data.

A show ver on the asa shows device manager V5.0.7

The field pix shows V6.3
I have access to both ends so updating the firmware is definitely an
option.
Any suggested version?

On the ASA side I do not have a no nat statement at all.  I never
configured
NAT because this device isn't beingused for any features other than a
VPN
access device with split tunneling enabled for the clients.
On the NY pix side the nat config and acl are as follows.

global (outside) 1 208.x.x.100-208.x.x.115 netmask 255.255.255.224
global (outside) 1 208.x.x.99 netmask 255.255.255.224
nat (inside) 0 access-list vpn-1
nat (inside) 1 0.0.0.0 0.0.0.0 0 0

access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
255.255.240.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
255.254.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
255.255.0.0

Thanks
Scott

----- Original Message ----- 
From: "Ryan West" <rwest at zyedge.com>
To: "Scott Granados" <gsgranados at comcast.net>;
<cisco-nsp at puck.nether.net>
Sent: Wednesday, September 02, 2009 6:15 AM
Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel


Scott,

Can you provide debugs from the ASA, code versions on both devices and
your
associated no-nat ACLs?

Assuming you have nothing else logging to monitor, you can enable
'logging
class vpn monitor debug' and throw up a term mon to gather inbound
messages
to the ASA from the PIX side.  You can gather the information on the PIX

with a debug cry isa 2 and then initiate interesting traffic from the
ASA
using the following, the more valuable information will be on the
receiving
end.  It really doesn't matter which side you enable as the receiver,
but I
try to stay away from pre 7.x code on the PIXes.

packet-tracer input inside icmp 10.1.0.10 8 0 10.18.15.10 detailed

Phase: 10 or 11 should be subtype encrypt.  If it fails the first time,
run
it again, the negotiation process causes the first packet to fail as the

tunnel is being brought.  This type of traffic will also give you your
debug
information and help you figure out where the failure is.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Tuesday, September 01, 2009 8:29 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

Hi, I have a Pix out in the field and an ASA5520 that I'm trying to
configure to pass L2L traffic.  I keep getting an error that says
IKEV1 IP=a.b.c.d removing peer from peer table failed, no match
ip=a.b.c.d unable to remove peer table entry

What am I doing wrong?

Here are the important config bits

asa-5520
crypto map
crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac
crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac
crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac
crypto dynamic-map dynmap 10 set transform-set vpn-transform1
vpn-transform2
vpn-transform3
crypto dynamic-map dynmap 10 set reverse-route
crypto map vpn-ra-map 10 match address ny-vpn-acl
crypto map vpn-ra-map 10 set peer ny-fw-outside
crypto map vpn-ra-map 10 set transform-set vpn-transform2
crypto map vpn-ra-map 10 set reverse-route
crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap
crypto map vpn-ra-map interface outside

ISAKMP

isakmp enable outside
isakmp policy 5 authentication pre-share
isakmp policy 5 encryption aes-256
isakmp policy 5 hash sha
isakmp policy 5 group 7
isakmp policy 5 lifetime 3600
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption aes-256
isakmp policy 10 hash sha
isakmp policy 10 group 5
isakmp policy 10 lifetime 3600
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 3600
isakmp policy 30 authentication pre-share
isakmp policy 30 encryption aes-192
isakmp policy 30 hash md5
isakmp policy 30 group 2
isakmp policy 30 lifetime 28800
isakmp nat-traversal  20
isakmp reload-wait

and the acl
access-list ny-vpn-acl extended permit ip 10.1.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.18.0.0 255.255.254.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.14.0.0 255.254.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 157.254.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 141.11.0.0 255.255.0.0
10.18.15.0
255.255.255.192
access-list ny-vpn-acl extended permit ip 10.11.0.0 255.255.0.0
10.18.15.0
255.255.255.192

TUNNEL GROUP

tunnel-group 208.37.161.98 type ipsec-l2l
tunnel-group 208.37.161.98 general-attributes
 tunnel-group 208.37.161.98 ipsec-attributes
 pre-shared-key *
 peer-id-validate nocheck

PIX

CRYPTO MAP and ISAKMP

crypto ipsec transform-set set1 esp-aes-192 esp-md5-hmac
crypto map map1 10 ipsec-isakmp
crypto map map1 10 match address vpn-1
crypto map map1 10 set peer vpnc
crypto map map1 10 set transform-set set1
crypto map map1 interface outside
isakmp enable outside
isakmp key *
 address vpnc netmask 255.255.255.255
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption aes
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 28800

ACL
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
255.255.240.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
255.254.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
255.255.0.0
access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
255.255.0.0

)note on the ASA I use individual /24's and shortened the ACL for ease
of
reasing.  I do this to exclued 10.18.14.0/24 from the tunnels since that
houses the ASA's inside interface and client access)

Any pointers would be appreciated.

Thanks
Scott

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From jckdaniels12 at gmail.com  Thu Sep  3 13:28:16 2009
From: jckdaniels12 at gmail.com (jack daniels)
Date: Thu, 3 Sep 2009 22:58:16 +0530
Subject: [c-nsp] mpls ldp sync
Message-ID: <8bb137f40909031028k2eaac39dr511a05a8d5abd26f@mail.gmail.com>

I'm in middle of a issue , request your help in this

issue -

We have a GSR 12416 connected to JUNIPER router.
We are running OSPF between them.
OSPF neighbourship comes up :) ....
BUT now when I enable under ospf "mpls ldp sync" --- ospf neighbourship goes
down and doesn't comes up. Request your help in this.

Regards
J.Daniels

From mksmith at adhost.com  Thu Sep  3 13:57:59 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Thu, 3 Sep 2009 10:57:59 -0700
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
In-Reply-To: <018601ca2cbd$bc8f7600$2208120a@am.thmulti.com>
References: <000501ca2b64$54ea36c0$0202fea9@am.thmulti.com><6E21B2BDEF6E714EA0B5BA8D5D0E1401248E269EB4@zy-ex1.zyedge.local>
	<00ea01ca2bec$cc3c98c0$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347A7@ad-exh01.adhost.lan>
	<012501ca2bf4$ec98c550$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347B1@ad-exh01.adhost.lan>
	<013501ca2bf7$74241a40$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347B8@ad-exh01.adhost.lan>
	<018601ca2cbd$bc8f7600$2208120a@am.thmulti.com>
Message-ID: <17838240D9A5544AAA5FF95F8D5203160693486A@ad-exh01.adhost.lan>

Hello Scott:

That error is something not matching up in the Phase 1 portion.  You
should look at the ISAKMP values on both sides to make sure they match.
Including, but not limited to, proposals, session key, lifetime values,
DH Group, etc.  

Regards,

Mike

--
Michael K. Smith - CISSP, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


> -----Original Message-----
> From: Scott Granados [mailto:gsgranados at comcast.net]
> Sent: Thursday, September 03, 2009 10:41 AM
> To: Michael K. Smith - Adhost
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> 
> Hi Mike and others, still no love.  I wanted to confirm I made the NAT
> entries properly.  I used the example on Cisco.com for the ASA and l2l
> +
> clients as an example.
> 
> 
> Here are the important bits
> 
> global (outside) 1 206.x.x.234
> nat (inside) 0 access-list nonat
> nat (inside) 1 0.0.0.0 0.0.0.0
> 
> And nonat acl
> 
> access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 192.168.122.0 255.255.255.192
> 10.18.14.0 255.255.255.0
> access-list nonat extended permit ip 157.254.0.0 255.255.0.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip host 216.x.x.196 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.0.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.1.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.2.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.3.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.4.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.5.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.6.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.7.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.8.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.9.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.10.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.15.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.15.0.0 255.255.0.0 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.32.0.0 255.240.0.0 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 192.168.255.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 172.30.0.0 255.255.0.0 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.11.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.12.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.13.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.16.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.192.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.224.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.225.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.226.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.227.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.228.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.229.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.230.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 192.168.122.0 255.255.255.192
> 10.18.15.0 255.255.255.192
> access-list nonat extended permit ip 157.254.0.0 255.255.0.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip host 216.x.x.196 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.0.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.1.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.2.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.3.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.4.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.5.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.6.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.7.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.8.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.9.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.10.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.15.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.15.0.0 255.255.0.0 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.32.0.0 255.240.0.0 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 192.168.255.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 172.30.0.0 255.255.0.0 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.11.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.12.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.13.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.16.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.1.192.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.1.224.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.1.225.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.1.226.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.1.227.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.1.228.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.1.229.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.1.230.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> 
> 
> Two points here.  I defined each as individual /24's to prevent the
> inclusion of the 10.18.14.0/24 range and so we can add or delete
easily
> because we're presently migrating a bit from one 10.x range to
another.
> Also, I doubled up the listings 1 for the destination of 10.18.14.0/24
> which
> is the clients and 10.18.15.0/26 which is a far end site.  Not sure if
> I'm
> heading in the other direction.  The error I received while trying to
> bring
> up the tunnel is unchanged.  "removing peer failed, no match!"
> 
> I did grab some debug output from the Pix side here's the important
bit
> 
> crypto_isakmp_process_block:src:vpnc, dest:208.x.x.98 spt:500 dpt:500
> ISAKMP: reserved not zero on payload 5!
> ISAKMP: malformed payload
> 
> I assume malformed payload means I have something set incorrectly
> during the
> negotiation phase.
> 
> Any pointers would be appreciated.  I will grab more debug data per
the
> other post but this is what I've tried so far.
> 
> Thanks
> Scott
> 
> ----- Original Message -----
> From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
> To: "Scott Granados" <gsgranados at comcast.net>
> Sent: Wednesday, September 02, 2009 11:03 AM
> Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> 
> 
> Correct.  But you can have multiple statements in your ACL.
> 
> Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.15.0
> 255.255.255.192
> Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.15.192
> 255.255.255.192
> Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.14.0
> 255.255.255.0
> 
> And so on.
> 
> Mike
> 
> --
> Michael K. Smith - CISSP, GISP
> Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
> w: +1 (206) 404-9500 f: +1 (206) 404-9050
> PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)
> 
> 
> -----Original Message-----
> From: Scott Granados [mailto:gsgranados at comcast.net]
> Sent: Wednesday, September 02, 2009 11:02 AM
> To: Michael K. Smith - Adhost; Ryan West; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> 
> Hi Michael, thanks but one thing I'm not clear on.
> 
> Suppose I have destinations of
> 10.18.15.0/26 10.18.15.192/26 10.18.14.0/24 etc.
> In other words my possible destinations can be different.  If I use
> your
> 
> example what happens if traffic has the proper source but a
destination
> of
> 10.18.15.192/26 or if traffic is destined to a client on
10.18.14.0/24?
> It
> won't match the ACL correct?
> 
> 
> ----- Original Message -----
> From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
> To: "Scott Granados" <gsgranados at comcast.net>; "Ryan West"
> <rwest at zyedge.com>; <cisco-nsp at puck.nether.net>
> Sent: Wednesday, September 02, 2009 10:47 AM
> Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> 
> 
> Hi Scott:
> 
> No, if you use the no-nat below, *all* traffic from 10.18.0.0/24 will
> not be NAT'd, regardless of the destination.  What you want is:
> 
> Access-list nonat permit ip 10.18.0.0 255.255.255.0 <remote subnet>
> <remote mask>
> 
> In looking at your post below, I think that would be:
> 
> Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.15.0
> 255.255.255.192
> 
> I should note that the mask on the remote side for the 10.18.0.0
subnet
> is a /20, not a /24.
> 
> Regards,
> 
> Mike
> 
> --
> Michael K. Smith - CISSP, GISP
> Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
> w: +1 (206) 404-9500 f: +1 (206) 404-9050
> PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)
> 
> 
> -----Original Message-----
> From: Scott Granados [mailto:gsgranados at comcast.net]
> Sent: Wednesday, September 02, 2009 10:44 AM
> To: Michael K. Smith - Adhost; Ryan West; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> 
> Hi Mike, to follow up on this, I do have existing clients working now.
> For
> the nonat rule would I create a sepperate ACL for each target or would
> a
> 
> basic acl like I use for the split tunneling do the trick?
> 
> either
> access-list ny-vpn extended permit ip 10.18.0.0 255.255.255.0
> 10.18.15.0
> 
> 255.255.255.192
> or would
> access-list nonat standard permit 10.18.0.0 255.255.255.0
> 
> I have several different targets so how would one define that or is
the
> standard ACL enough?
> 
> Thanks for the pointers!
> Scott
> 
> ----- Original Message -----
> From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
> To: "Scott Granados" <gsgranados at comcast.net>; "Ryan West"
> <rwest at zyedge.com>; <cisco-nsp at puck.nether.net>
> Sent: Wednesday, September 02, 2009 10:33 AM
> Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> 
> 
> Hello Ryan:
> 
> Without the no-nat on the ASA side it will try to NAT the traffic
> before
> putting it down the tunnel.  So, you're remove side is looking for the
> 10. Addresses, but it's going to see traffic coming from the static
> outside, NAT'd address.  Thus, the tunnel won't come up because your
> proposals don't match.
> 
> Mike
> 
> --
> Michael K. Smith - CISSP, GISP
> Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
> w: +1 (206) 404-9500 f: +1 (206) 404-9050
> PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)
> 
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
> Sent: Wednesday, September 02, 2009 9:45 AM
> To: Ryan West; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> 
> Hi, so right now my Pix in the field is pointing at a VPN 3000 so I
> can't
> take that path down until after hours but I will to capture the debug
> data.
> 
> A show ver on the asa shows device manager V5.0.7
> 
> The field pix shows V6.3
> I have access to both ends so updating the firmware is definitely an
> option.
> Any suggested version?
> 
> On the ASA side I do not have a no nat statement at all.  I never
> configured
> NAT because this device isn't beingused for any features other than a
> VPN
> access device with split tunneling enabled for the clients.
> On the NY pix side the nat config and acl are as follows.
> 
> global (outside) 1 208.x.x.100-208.x.x.115 netmask 255.255.255.224
> global (outside) 1 208.x.x.99 netmask 255.255.255.224
> nat (inside) 0 access-list vpn-1
> nat (inside) 1 0.0.0.0 0.0.0.0 0 0
> 
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
> 255.255.0.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
> 255.255.240.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
> 255.254.0.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
> 255.255.0.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
> 255.255.0.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
> 255.255.0.0
> 
> Thanks
> Scott
> 
> ----- Original Message -----
> From: "Ryan West" <rwest at zyedge.com>
> To: "Scott Granados" <gsgranados at comcast.net>;
> <cisco-nsp at puck.nether.net>
> Sent: Wednesday, September 02, 2009 6:15 AM
> Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> 
> 
> Scott,
> 
> Can you provide debugs from the ASA, code versions on both devices and
> your
> associated no-nat ACLs?
> 
> Assuming you have nothing else logging to monitor, you can enable
> 'logging
> class vpn monitor debug' and throw up a term mon to gather inbound
> messages
> to the ASA from the PIX side.  You can gather the information on the
> PIX
> 
> with a debug cry isa 2 and then initiate interesting traffic from the
> ASA
> using the following, the more valuable information will be on the
> receiving
> end.  It really doesn't matter which side you enable as the receiver,
> but I
> try to stay away from pre 7.x code on the PIXes.
> 
> packet-tracer input inside icmp 10.1.0.10 8 0 10.18.15.10 detailed
> 
> Phase: 10 or 11 should be subtype encrypt.  If it fails the first
time,
> run
> it again, the negotiation process causes the first packet to fail as
> the
> 
> tunnel is being brought.  This type of traffic will also give you your
> debug
> information and help you figure out where the failure is.
> 
> -ryan
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
> Sent: Tuesday, September 01, 2009 8:29 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> 
> Hi, I have a Pix out in the field and an ASA5520 that I'm trying to
> configure to pass L2L traffic.  I keep getting an error that says
> IKEV1 IP=a.b.c.d removing peer from peer table failed, no match
> ip=a.b.c.d unable to remove peer table entry
> 
> What am I doing wrong?
> 
> Here are the important config bits
> 
> asa-5520
> crypto map
> crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac
> crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac
> crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac
> crypto dynamic-map dynmap 10 set transform-set vpn-transform1
> vpn-transform2
> vpn-transform3
> crypto dynamic-map dynmap 10 set reverse-route
> crypto map vpn-ra-map 10 match address ny-vpn-acl
> crypto map vpn-ra-map 10 set peer ny-fw-outside
> crypto map vpn-ra-map 10 set transform-set vpn-transform2
> crypto map vpn-ra-map 10 set reverse-route
> crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap
> crypto map vpn-ra-map interface outside
> 
> ISAKMP
> 
> isakmp enable outside
> isakmp policy 5 authentication pre-share
> isakmp policy 5 encryption aes-256
> isakmp policy 5 hash sha
> isakmp policy 5 group 7
> isakmp policy 5 lifetime 3600
> isakmp policy 10 authentication pre-share
> isakmp policy 10 encryption aes-256
> isakmp policy 10 hash sha
> isakmp policy 10 group 5
> isakmp policy 10 lifetime 3600
> isakmp policy 20 authentication pre-share
> isakmp policy 20 encryption 3des
> isakmp policy 20 hash sha
> isakmp policy 20 group 2
> isakmp policy 20 lifetime 3600
> isakmp policy 30 authentication pre-share
> isakmp policy 30 encryption aes-192
> isakmp policy 30 hash md5
> isakmp policy 30 group 2
> isakmp policy 30 lifetime 28800
> isakmp nat-traversal  20
> isakmp reload-wait
> 
> and the acl
> access-list ny-vpn-acl extended permit ip 10.1.0.0 255.255.0.0
> 10.18.15.0
> 255.255.255.192
> access-list ny-vpn-acl extended permit ip 10.18.0.0 255.255.254.0
> 10.18.15.0
> 255.255.255.192
> access-list ny-vpn-acl extended permit ip 10.14.0.0 255.254.0.0
> 10.18.15.0
> 255.255.255.192
> access-list ny-vpn-acl extended permit ip 157.254.0.0 255.255.0.0
> 10.18.15.0
> 255.255.255.192
> access-list ny-vpn-acl extended permit ip 141.11.0.0 255.255.0.0
> 10.18.15.0
> 255.255.255.192
> access-list ny-vpn-acl extended permit ip 10.11.0.0 255.255.0.0
> 10.18.15.0
> 255.255.255.192
> 
> TUNNEL GROUP
> 
> tunnel-group 208.37.161.98 type ipsec-l2l
> tunnel-group 208.37.161.98 general-attributes
>  tunnel-group 208.37.161.98 ipsec-attributes
>  pre-shared-key *
>  peer-id-validate nocheck
> 
> PIX
> 
> CRYPTO MAP and ISAKMP
> 
> crypto ipsec transform-set set1 esp-aes-192 esp-md5-hmac
> crypto map map1 10 ipsec-isakmp
> crypto map map1 10 match address vpn-1
> crypto map map1 10 set peer vpnc
> crypto map map1 10 set transform-set set1
> crypto map map1 interface outside
> isakmp enable outside
> isakmp key *
>  address vpnc netmask 255.255.255.255
> isakmp policy 20 authentication pre-share
> isakmp policy 20 encryption aes
> isakmp policy 20 hash sha
> isakmp policy 20 group 2
> isakmp policy 20 lifetime 28800
> 
> ACL
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
> 255.255.0.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
> 255.255.240.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
> 255.254.0.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
> 255.255.0.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
> 255.255.0.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
> 255.255.0.0
> 
> )note on the ASA I use individual /24's and shortened the ACL for ease
> of
> reasing.  I do this to exclued 10.18.14.0/24 from the tunnels since
> that
> houses the ASA's inside interface and client access)
> 
> Any pointers would be appreciated.
> 
> Thanks
> Scott
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From swmike at swm.pp.se  Thu Sep  3 14:10:19 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Thu, 3 Sep 2009 20:10:19 +0200 (CEST)
Subject: [c-nsp] mpls ldp sync
In-Reply-To: <8bb137f40909031028k2eaac39dr511a05a8d5abd26f@mail.gmail.com>
References: <8bb137f40909031028k2eaac39dr511a05a8d5abd26f@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.0909032010040.20805@uplift.swm.pp.se>

On Thu, 3 Sep 2009, jack daniels wrote:

> BUT now when I enable under ospf "mpls ldp sync" --- ospf neighbourship 
> goes down and doesn't comes up. Request your help in this.

Is LDP up between them? If not, then that's why.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se

From svemulap at cisco.com  Thu Sep  3 14:10:11 2009
From: svemulap at cisco.com (Shankar Vemulapalli (svemulap))
Date: Thu, 3 Sep 2009 11:10:11 -0700
Subject: [c-nsp] mpls ldp sync
In-Reply-To: <8bb137f40909031028k2eaac39dr511a05a8d5abd26f@mail.gmail.com>
References: <8bb137f40909031028k2eaac39dr511a05a8d5abd26f@mail.gmail.com>
Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0E092A1E25@xmb-sjc-234.amer.cisco.com>

Daniels - 

Did you configure on the Juniper side too ?? [mpls ldp sync] 
Are you running OSPF as IGP and which release on GSR ? 

Try changing the holddown timer to see if it makes a change. 
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fsldpsyn.html#wp
1100282

/Shankar

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of jack daniels
Sent: Thursday, September 03, 2009 10:28 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] mpls ldp sync

I'm in middle of a issue , request your help in this

issue -

We have a GSR 12416 connected to JUNIPER router.
We are running OSPF between them.
OSPF neighbourship comes up :) ....
BUT now when I enable under ospf "mpls ldp sync" --- ospf neighbourship
goes
down and doesn't comes up. Request your help in this.

Regards
J.Daniels
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From DLasher at newedgenetworks.com  Thu Sep  3 13:42:37 2009
From: DLasher at newedgenetworks.com (Lasher, Donn)
Date: Thu, 3 Sep 2009 10:42:37 -0700
Subject: [c-nsp] Management stuff in VRFs
In-Reply-To: <4A9F7B7E.9030202@renater.fr>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>
	<4A9F7B7E.9030202@renater.fr>
Message-ID: <C97F73E15F1F0D48A3AC0C423F8C221A01ACD22E@rancor.ad.newedgenetworks.com>

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jerome Durand
Subject: Re: [c-nsp] Management stuff in VRFs

>We went in that direction in our latest deployment and discovered also 
>that many pieces were missing in IOS and IOS-XR to have full management

>in a dedicated VRF for all our devices.

>At this stage we have the VRF but not all management goes there... so 
>there is more complexity and network is no more secure... I must admit 
>IOS-XR gives us more troubles as more management features are missing
in 
>VRF's.

The most effective way to do this I've seen so far essentially turns
your network inside out. The "Global" portion of the router is
management, in RFC1918 space, and your "internet/public"
IP's/traffic/etc are all carried in a dedicated VRF.

Taking a production network NOT designed that way, and doing the
inside-out... well.... that's every bit as hard as it sounds...



From rjs at eng.gxn.net  Thu Sep  3 14:30:04 2009
From: rjs at eng.gxn.net (Rob Shakir)
Date: Thu, 3 Sep 2009 19:30:04 +0100
Subject: [c-nsp] do i *need* DFCs on the 6500?
In-Reply-To: <1251895351.2991.58.camel@abehat.net.rm.dk>
References: <20090902111616.GA6588@lboro.ac.uk>
	<alpine.DEB.1.10.0909021400050.20521@uplift.swm.pp.se>
	<1251895351.2991.58.camel@abehat.net.rm.dk>
Message-ID: <20090903183004.GF5351@cappuccino.rob.sh>

On Wed, Sep 02, 2009 at 02:42:31PM +0200, Peter Rathlev wrote:
> Agreed, and introducing DFCs can give you some headaches with e.g.
> policers, since each forwarding engine operates independently from the
> others.

I guess here you're referring to the fact that there is no communication of
ingress rates between individual DFCs, or back to the PFC? I posed this question
to Cisco at a CPOC lab, and have also heard the same from TAC. Consider the
following scenario:

Two flows are ingress on a 6500, one on Gi1/0 (where slot 1 has a DFC), and one
on Gi2/0 (where slot 2 also has a DFC). They are egress on a third port Gi3/0,
which also has a DFC. Since the policing is performed by the ingress LC, if
Gi3/0 has a 50Mbps policer, and the flows at Gi1/0 and Gi2/0 are both 40Mbps,
neither card will drop any packets, and hence the egress rate at port Gi3/0 is
80Mbps, despite having a 50Mbps policer configured.

Unfortunately, I don't have the resources to test this - has anyone tried this
scenario, and verified this is _actually_ how things work, rather than
theoretically?

(I think the official answer for this was..."This will be fixed in EARL 8")

Thanks,
Rob

-- 
Rob Shakir                      <rjs at eng.gxn.net>
Network Development Engineer    GX Networks/Vialtus Solutions
ddi: +44208 587 6077            mob: +44797 155 4098
pgp: 0xc07e6deb                 nic-hdl: RJS-RIPE

This email is subject to: http//www.vialtus.com/disclaimer.html


From rwest at zyedge.com  Thu Sep  3 14:39:18 2009
From: rwest at zyedge.com (Ryan West)
Date: Thu, 3 Sep 2009 14:39:18 -0400
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
In-Reply-To: <018601ca2cbd$bc8f7600$2208120a@am.thmulti.com>
References: <000501ca2b64$54ea36c0$0202fea9@am.thmulti.com><6E21B2BDEF6E714EA0B5BA8D5D0E1401248E269EB4@zy-ex1.zyedge.local>
	<00ea01ca2bec$cc3c98c0$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347A7@ad-exh01.adhost.lan>
	<012501ca2bf4$ec98c550$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347B1@ad-exh01.adhost.lan>
	<013501ca2bf7$74241a40$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347B8@ad-exh01.adhost.lan>
	<018601ca2cbd$bc8f7600$2208120a@am.thmulti.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248E269FA3@zy-ex1.zyedge.local>

Scott,

A pointer for your ACLs, wrap up your secured networks into two object-groups.  For example:

Object-group network internal 
 Network-object 10.1.0.0 255.255.0.0
 Network-object 10.1.0.0 255.255.0.0
.....

Object-group network ny_nets
 Network-object 10.18.14.0 255.255.255.0

Then craft your interesting traffic ACL on the ASA to look something like this:

Access-list vpn_ny permit ip object-group internal object-group ny_nets

Access-list nonat permit ip object-group internal object-group ny_nets

Any future changes are done at the object-groups and will be immediately reflected in your interesting traffic ACL and nonat ACL.

As Michael has said, the error can be a number of things, I would start with the crypto key though.  A lot of the ISAKMP settings (at least in the ASA) are part of the default config and cover just about every common Phase1 setting.  From the ASA, issue a 'show cry isa sa detail' and check out the entry that corresponds with your PIX endpoint.  Post the results of that once you've got a stream of interesting traffic going from the ASA to the PIX.  If possible post the debug results from the PIX to the ASA with the settings that I mentioned earlier, if there is a key mismatch, you'll see that error on the ASA side.

In case you're curious, this is the 7.2.4 bug I was referring to as well, it exists through 7.2.4(18):

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsq91271

-ryan

-----Original Message-----



Scott,

Can you provide debugs from the ASA, code versions on both devices and
your
associated no-nat ACLs?

Assuming you have nothing else logging to monitor, you can enable
'logging
class vpn monitor debug' and throw up a term mon to gather inbound
messages
to the ASA from the PIX side.  You can gather the information on the PIX

with a debug cry isa 2 and then initiate interesting traffic from the
ASA
using the following, the more valuable information will be on the
receiving
end.  It really doesn't matter which side you enable as the receiver,
but I
try to stay away from pre 7.x code on the PIXes.

packet-tracer input inside icmp 10.1.0.10 8 0 10.18.15.10 detailed

Phase: 10 or 11 should be subtype encrypt.  If it fails the first time,
run
it again, the negotiation process causes the first packet to fail as the

tunnel is being brought.  This type of traffic will also give you your
debug
information and help you figure out where the failure is.

-ryan



From gsgranados at comcast.net  Thu Sep  3 15:09:12 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Thu, 3 Sep 2009 12:09:12 -0700
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
References: <000501ca2b64$54ea36c0$0202fea9@am.thmulti.com><6E21B2BDEF6E714EA0B5BA8D5D0E1401248E269EB4@zy-ex1.zyedge.local>
	<00ea01ca2bec$cc3c98c0$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347A7@ad-exh01.adhost.lan>
	<012501ca2bf4$ec98c550$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347B1@ad-exh01.adhost.lan>
	<013501ca2bf7$74241a40$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347B8@ad-exh01.adhost.lan>
	<018601ca2cbd$bc8f7600$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D5203160693486A@ad-exh01.adhost.lan>
Message-ID: <01e001ca2cca$0aae9530$2208120a@am.thmulti.com>

Ah interesting.  So the lifetimes have to be the same, I thought it 
negotiated to the lowest value.  I will go through and check these.

Thank you again!


----- Original Message ----- 
From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
To: "Scott Granados" <gsgranados at comcast.net>
Cc: <cisco-nsp at puck.nether.net>
Sent: Thursday, September 03, 2009 10:57 AM
Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel


Hello Scott:

That error is something not matching up in the Phase 1 portion.  You
should look at the ISAKMP values on both sides to make sure they match.
Including, but not limited to, proposals, session key, lifetime values,
DH Group, etc.

Regards,

Mike

--
Michael K. Smith - CISSP, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


> -----Original Message-----
> From: Scott Granados [mailto:gsgranados at comcast.net]
> Sent: Thursday, September 03, 2009 10:41 AM
> To: Michael K. Smith - Adhost
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
>
> Hi Mike and others, still no love.  I wanted to confirm I made the NAT
> entries properly.  I used the example on Cisco.com for the ASA and l2l
> +
> clients as an example.
>
>
> Here are the important bits
>
> global (outside) 1 206.x.x.234
> nat (inside) 0 access-list nonat
> nat (inside) 1 0.0.0.0 0.0.0.0
>
> And nonat acl
>
> access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 192.168.122.0 255.255.255.192
> 10.18.14.0 255.255.255.0
> access-list nonat extended permit ip 157.254.0.0 255.255.0.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip host 216.x.x.196 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.0.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.1.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.2.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.3.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.4.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.5.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.6.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.7.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.8.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.9.0 255.255.255.0
10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.10.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.15.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.15.0.0 255.255.0.0 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.32.0.0 255.240.0.0 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 192.168.255.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 172.30.0.0 255.255.0.0 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.11.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.12.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.13.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.18.16.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.192.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.224.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.225.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.226.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.227.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.228.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.229.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.230.0 255.255.255.0
> 10.18.14.0
> 255.255.255.0
> access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 192.168.122.0 255.255.255.192
> 10.18.15.0 255.255.255.192
> access-list nonat extended permit ip 157.254.0.0 255.255.0.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip host 216.x.x.196 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.0.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.1.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.2.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.3.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.4.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.5.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.6.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.7.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.8.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.9.0 255.255.255.0
10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.10.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.15.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.15.0.0 255.255.0.0 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.32.0.0 255.240.0.0 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 192.168.255.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 172.30.0.0 255.255.0.0 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.11.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.12.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.13.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.18.16.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.1.192.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.1.224.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.1.225.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.1.226.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.1.227.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.1.228.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.1.229.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
> access-list nonat extended permit ip 10.1.230.0 255.255.255.0
> 10.18.15.0
> 255.255.255.192
>
>
> Two points here.  I defined each as individual /24's to prevent the
> inclusion of the 10.18.14.0/24 range and so we can add or delete
easily
> because we're presently migrating a bit from one 10.x range to
another.
> Also, I doubled up the listings 1 for the destination of 10.18.14.0/24
> which
> is the clients and 10.18.15.0/26 which is a far end site.  Not sure if
> I'm
> heading in the other direction.  The error I received while trying to
> bring
> up the tunnel is unchanged.  "removing peer failed, no match!"
>
> I did grab some debug output from the Pix side here's the important
bit
>
> crypto_isakmp_process_block:src:vpnc, dest:208.x.x.98 spt:500 dpt:500
> ISAKMP: reserved not zero on payload 5!
> ISAKMP: malformed payload
>
> I assume malformed payload means I have something set incorrectly
> during the
> negotiation phase.
>
> Any pointers would be appreciated.  I will grab more debug data per
the
> other post but this is what I've tried so far.
>
> Thanks
> Scott
>
> ----- Original Message -----
> From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
> To: "Scott Granados" <gsgranados at comcast.net>
> Sent: Wednesday, September 02, 2009 11:03 AM
> Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
>
>
> Correct.  But you can have multiple statements in your ACL.
>
> Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.15.0
> 255.255.255.192
> Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.15.192
> 255.255.255.192
> Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.14.0
> 255.255.255.0
>
> And so on.
>
> Mike
>
> --
> Michael K. Smith - CISSP, GISP
> Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
> w: +1 (206) 404-9500 f: +1 (206) 404-9050
> PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)
>
>
> -----Original Message-----
> From: Scott Granados [mailto:gsgranados at comcast.net]
> Sent: Wednesday, September 02, 2009 11:02 AM
> To: Michael K. Smith - Adhost; Ryan West; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
>
> Hi Michael, thanks but one thing I'm not clear on.
>
> Suppose I have destinations of
> 10.18.15.0/26 10.18.15.192/26 10.18.14.0/24 etc.
> In other words my possible destinations can be different.  If I use
> your
>
> example what happens if traffic has the proper source but a
destination
> of
> 10.18.15.192/26 or if traffic is destined to a client on
10.18.14.0/24?
> It
> won't match the ACL correct?
>
>
> ----- Original Message -----
> From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
> To: "Scott Granados" <gsgranados at comcast.net>; "Ryan West"
> <rwest at zyedge.com>; <cisco-nsp at puck.nether.net>
> Sent: Wednesday, September 02, 2009 10:47 AM
> Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
>
>
> Hi Scott:
>
> No, if you use the no-nat below, *all* traffic from 10.18.0.0/24 will
> not be NAT'd, regardless of the destination.  What you want is:
>
> Access-list nonat permit ip 10.18.0.0 255.255.255.0 <remote subnet>
> <remote mask>
>
> In looking at your post below, I think that would be:
>
> Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.15.0
> 255.255.255.192
>
> I should note that the mask on the remote side for the 10.18.0.0
subnet
> is a /20, not a /24.
>
> Regards,
>
> Mike
>
> --
> Michael K. Smith - CISSP, GISP
> Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
> w: +1 (206) 404-9500 f: +1 (206) 404-9050
> PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)
>
>
> -----Original Message-----
> From: Scott Granados [mailto:gsgranados at comcast.net]
> Sent: Wednesday, September 02, 2009 10:44 AM
> To: Michael K. Smith - Adhost; Ryan West; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
>
> Hi Mike, to follow up on this, I do have existing clients working now.
> For
> the nonat rule would I create a sepperate ACL for each target or would
> a
>
> basic acl like I use for the split tunneling do the trick?
>
> either
> access-list ny-vpn extended permit ip 10.18.0.0 255.255.255.0
> 10.18.15.0
>
> 255.255.255.192
> or would
> access-list nonat standard permit 10.18.0.0 255.255.255.0
>
> I have several different targets so how would one define that or is
the
> standard ACL enough?
>
> Thanks for the pointers!
> Scott
>
> ----- Original Message -----
> From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
> To: "Scott Granados" <gsgranados at comcast.net>; "Ryan West"
> <rwest at zyedge.com>; <cisco-nsp at puck.nether.net>
> Sent: Wednesday, September 02, 2009 10:33 AM
> Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
>
>
> Hello Ryan:
>
> Without the no-nat on the ASA side it will try to NAT the traffic
> before
> putting it down the tunnel.  So, you're remove side is looking for the
> 10. Addresses, but it's going to see traffic coming from the static
> outside, NAT'd address.  Thus, the tunnel won't come up because your
> proposals don't match.
>
> Mike
>
> --
> Michael K. Smith - CISSP, GISP
> Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
> w: +1 (206) 404-9500 f: +1 (206) 404-9050
> PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
> Sent: Wednesday, September 02, 2009 9:45 AM
> To: Ryan West; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
>
> Hi, so right now my Pix in the field is pointing at a VPN 3000 so I
> can't
> take that path down until after hours but I will to capture the debug
> data.
>
> A show ver on the asa shows device manager V5.0.7
>
> The field pix shows V6.3
> I have access to both ends so updating the firmware is definitely an
> option.
> Any suggested version?
>
> On the ASA side I do not have a no nat statement at all.  I never
> configured
> NAT because this device isn't beingused for any features other than a
> VPN
> access device with split tunneling enabled for the clients.
> On the NY pix side the nat config and acl are as follows.
>
> global (outside) 1 208.x.x.100-208.x.x.115 netmask 255.255.255.224
> global (outside) 1 208.x.x.99 netmask 255.255.255.224
> nat (inside) 0 access-list vpn-1
> nat (inside) 1 0.0.0.0 0.0.0.0 0 0
>
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
> 255.255.0.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
> 255.255.240.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
> 255.254.0.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
> 255.255.0.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
> 255.255.0.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
> 255.255.0.0
>
> Thanks
> Scott
>
> ----- Original Message -----
> From: "Ryan West" <rwest at zyedge.com>
> To: "Scott Granados" <gsgranados at comcast.net>;
> <cisco-nsp at puck.nether.net>
> Sent: Wednesday, September 02, 2009 6:15 AM
> Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
>
>
> Scott,
>
> Can you provide debugs from the ASA, code versions on both devices and
> your
> associated no-nat ACLs?
>
> Assuming you have nothing else logging to monitor, you can enable
> 'logging
> class vpn monitor debug' and throw up a term mon to gather inbound
> messages
> to the ASA from the PIX side.  You can gather the information on the
> PIX
>
> with a debug cry isa 2 and then initiate interesting traffic from the
> ASA
> using the following, the more valuable information will be on the
> receiving
> end.  It really doesn't matter which side you enable as the receiver,
> but I
> try to stay away from pre 7.x code on the PIXes.
>
> packet-tracer input inside icmp 10.1.0.10 8 0 10.18.15.10 detailed
>
> Phase: 10 or 11 should be subtype encrypt.  If it fails the first
time,
> run
> it again, the negotiation process causes the first packet to fail as
> the
>
> tunnel is being brought.  This type of traffic will also give you your
> debug
> information and help you figure out where the failure is.
>
> -ryan
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
> Sent: Tuesday, September 01, 2009 8:29 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
>
> Hi, I have a Pix out in the field and an ASA5520 that I'm trying to
> configure to pass L2L traffic.  I keep getting an error that says
> IKEV1 IP=a.b.c.d removing peer from peer table failed, no match
> ip=a.b.c.d unable to remove peer table entry
>
> What am I doing wrong?
>
> Here are the important config bits
>
> asa-5520
> crypto map
> crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac
> crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac
> crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac
> crypto dynamic-map dynmap 10 set transform-set vpn-transform1
> vpn-transform2
> vpn-transform3
> crypto dynamic-map dynmap 10 set reverse-route
> crypto map vpn-ra-map 10 match address ny-vpn-acl
> crypto map vpn-ra-map 10 set peer ny-fw-outside
> crypto map vpn-ra-map 10 set transform-set vpn-transform2
> crypto map vpn-ra-map 10 set reverse-route
> crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap
> crypto map vpn-ra-map interface outside
>
> ISAKMP
>
> isakmp enable outside
> isakmp policy 5 authentication pre-share
> isakmp policy 5 encryption aes-256
> isakmp policy 5 hash sha
> isakmp policy 5 group 7
> isakmp policy 5 lifetime 3600
> isakmp policy 10 authentication pre-share
> isakmp policy 10 encryption aes-256
> isakmp policy 10 hash sha
> isakmp policy 10 group 5
> isakmp policy 10 lifetime 3600
> isakmp policy 20 authentication pre-share
> isakmp policy 20 encryption 3des
> isakmp policy 20 hash sha
> isakmp policy 20 group 2
> isakmp policy 20 lifetime 3600
> isakmp policy 30 authentication pre-share
> isakmp policy 30 encryption aes-192
> isakmp policy 30 hash md5
> isakmp policy 30 group 2
> isakmp policy 30 lifetime 28800
> isakmp nat-traversal  20
> isakmp reload-wait
>
> and the acl
> access-list ny-vpn-acl extended permit ip 10.1.0.0 255.255.0.0
> 10.18.15.0
> 255.255.255.192
> access-list ny-vpn-acl extended permit ip 10.18.0.0 255.255.254.0
> 10.18.15.0
> 255.255.255.192
> access-list ny-vpn-acl extended permit ip 10.14.0.0 255.254.0.0
> 10.18.15.0
> 255.255.255.192
> access-list ny-vpn-acl extended permit ip 157.254.0.0 255.255.0.0
> 10.18.15.0
> 255.255.255.192
> access-list ny-vpn-acl extended permit ip 141.11.0.0 255.255.0.0
> 10.18.15.0
> 255.255.255.192
> access-list ny-vpn-acl extended permit ip 10.11.0.0 255.255.0.0
> 10.18.15.0
> 255.255.255.192
>
> TUNNEL GROUP
>
> tunnel-group 208.37.161.98 type ipsec-l2l
> tunnel-group 208.37.161.98 general-attributes
>  tunnel-group 208.37.161.98 ipsec-attributes
>  pre-shared-key *
>  peer-id-validate nocheck
>
> PIX
>
> CRYPTO MAP and ISAKMP
>
> crypto ipsec transform-set set1 esp-aes-192 esp-md5-hmac
> crypto map map1 10 ipsec-isakmp
> crypto map map1 10 match address vpn-1
> crypto map map1 10 set peer vpnc
> crypto map map1 10 set transform-set set1
> crypto map map1 interface outside
> isakmp enable outside
> isakmp key *
>  address vpnc netmask 255.255.255.255
> isakmp policy 20 authentication pre-share
> isakmp policy 20 encryption aes
> isakmp policy 20 hash sha
> isakmp policy 20 group 2
> isakmp policy 20 lifetime 28800
>
> ACL
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
> 255.255.0.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
> 255.255.240.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
> 255.254.0.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
> 255.255.0.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
> 255.255.0.0
> access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
> 255.255.0.0
>
> )note on the ASA I use individual /24's and shortened the ACL for ease
> of
> reasing.  I do this to exclued 10.18.14.0/24 from the tunnels since
> that
> houses the ASA's inside interface and client access)
>
> Any pointers would be appreciated.
>
> Thanks
> Scott
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From alex at erus.co.uk  Thu Sep  3 14:16:27 2009
From: alex at erus.co.uk (Alex Pimperton)
Date: Thu, 3 Sep 2009 19:16:27 +0100
Subject: [c-nsp] HWIC-1ADSL-M
Message-ID: <000501ca2cc2$a7dc4a30$f794de90$@co.uk>

Hi,

Reading through the specs for the above card Cisco mentions not supporting
"UK Mask".

Does this mean the card doesn't work for ADSL-M (Seemingly often branded as
SDSL-M) in the UK?

We're looking at getting some SDSL-M circuits to see what they're like, from
Spitfire and Nildram (Tiscali), anybody using either HWIC-1ADSL-M or C877-M
with those providers Annex M services?

Anybody using the above products with any Annex-M products in the UK?

Any info would be great, as these products are fairly new Google doesn't
turn up anything and the Cisco kit is not on the published lists of
compatible CPE equipment.

Alex



-- 
This message has been scanned for viruses and
dangerous content by AxTech, and is
believed to be clean.


From mksmith at adhost.com  Thu Sep  3 15:20:41 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Thu, 3 Sep 2009 12:20:41 -0700
Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
In-Reply-To: <01e001ca2cca$0aae9530$2208120a@am.thmulti.com>
References: <000501ca2b64$54ea36c0$0202fea9@am.thmulti.com><6E21B2BDEF6E714EA0B5BA8D5D0E1401248E269EB4@zy-ex1.zyedge.local>
	<00ea01ca2bec$cc3c98c0$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347A7@ad-exh01.adhost.lan>
	<012501ca2bf4$ec98c550$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347B1@ad-exh01.adhost.lan>
	<013501ca2bf7$74241a40$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D520316069347B8@ad-exh01.adhost.lan>
	<018601ca2cbd$bc8f7600$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D5203160693486A@ad-exh01.adhost.lan>
	<01e001ca2cca$0aae9530$2208120a@am.thmulti.com>
Message-ID: <17838240D9A5544AAA5FF95F8D5203160693488B@ad-exh01.adhost.lan>

Hi Scott:

They will set to the lowest, but it's always a good idea for everything
to match.

Mike

--
Michael K. Smith - CISSP, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


> -----Original Message-----
> From: Scott Granados [mailto:gsgranados at comcast.net]
> Sent: Thursday, September 03, 2009 12:09 PM
> To: Michael K. Smith - Adhost
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> 
> Ah interesting.  So the lifetimes have to be the same, I thought it
> negotiated to the lowest value.  I will go through and check these.
> 
> Thank you again!
> 
> 
> ----- Original Message -----
> From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
> To: "Scott Granados" <gsgranados at comcast.net>
> Cc: <cisco-nsp at puck.nether.net>
> Sent: Thursday, September 03, 2009 10:57 AM
> Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> 
> 
> Hello Scott:
> 
> That error is something not matching up in the Phase 1 portion.  You
> should look at the ISAKMP values on both sides to make sure they
match.
> Including, but not limited to, proposals, session key, lifetime
values,
> DH Group, etc.
> 
> Regards,
> 
> Mike
> 
> --
> Michael K. Smith - CISSP, GISP
> Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
> w: +1 (206) 404-9500 f: +1 (206) 404-9050
> PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)
> 
> 
> > -----Original Message-----
> > From: Scott Granados [mailto:gsgranados at comcast.net]
> > Sent: Thursday, September 03, 2009 10:41 AM
> > To: Michael K. Smith - Adhost
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> >
> > Hi Mike and others, still no love.  I wanted to confirm I made the
> NAT
> > entries properly.  I used the example on Cisco.com for the ASA and
> l2l
> > +
> > clients as an example.
> >
> >
> > Here are the important bits
> >
> > global (outside) 1 206.x.x.234
> > nat (inside) 0 access-list nonat
> > nat (inside) 1 0.0.0.0 0.0.0.0
> >
> > And nonat acl
> >
> > access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.11.0.0 255.255.0.0
10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.64.0.0 255.255.0.0
10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.66.0.0 255.255.0.0
10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 141.11.0.0 255.255.0.0
> 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 192.168.122.0 255.255.255.192
> > 10.18.14.0 255.255.255.0
> > access-list nonat extended permit ip 157.254.0.0 255.255.0.0
> 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip host 216.x.x.196 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.18.0.0 255.255.255.0
> 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.18.1.0 255.255.255.0
> 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.18.2.0 255.255.255.0
> 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.18.3.0 255.255.255.0
> 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.18.4.0 255.255.255.0
> 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.18.5.0 255.255.255.0
> 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.18.6.0 255.255.255.0
> 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.18.7.0 255.255.255.0
> 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.18.8.0 255.255.255.0
> 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.18.9.0 255.255.255.0
> 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.18.10.0 255.255.255.0
> > 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.18.15.0 255.255.255.0
> > 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.15.0.0 255.255.0.0
10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.32.0.0 255.240.0.0
10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 192.168.255.0 255.255.255.0
> > 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 172.30.0.0 255.255.0.0
> 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.18.11.0 255.255.255.0
> > 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.18.12.0 255.255.255.0
> > 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.18.13.0 255.255.255.0
> > 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.18.16.0 255.255.255.0
> > 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.1.192.0 255.255.255.0
> > 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.1.224.0 255.255.255.0
> > 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.1.225.0 255.255.255.0
> > 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.1.226.0 255.255.255.0
> > 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.1.227.0 255.255.255.0
> > 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.1.228.0 255.255.255.0
> > 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.1.229.0 255.255.255.0
> > 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.1.230.0 255.255.255.0
> > 10.18.14.0
> > 255.255.255.0
> > access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.11.0.0 255.255.0.0
10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.64.0.0 255.255.0.0
10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.66.0.0 255.255.0.0
10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 141.11.0.0 255.255.0.0
> 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 192.168.122.0 255.255.255.192
> > 10.18.15.0 255.255.255.192
> > access-list nonat extended permit ip 157.254.0.0 255.255.0.0
> 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip host 216.x.x.196 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.18.0.0 255.255.255.0
> 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.18.1.0 255.255.255.0
> 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.18.2.0 255.255.255.0
> 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.18.3.0 255.255.255.0
> 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.18.4.0 255.255.255.0
> 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.18.5.0 255.255.255.0
> 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.18.6.0 255.255.255.0
> 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.18.7.0 255.255.255.0
> 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.18.8.0 255.255.255.0
> 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.18.9.0 255.255.255.0
> 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.18.10.0 255.255.255.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.18.15.0 255.255.255.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.15.0.0 255.255.0.0
10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.32.0.0 255.240.0.0
10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 192.168.255.0 255.255.255.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 172.30.0.0 255.255.0.0
> 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.18.11.0 255.255.255.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.18.12.0 255.255.255.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.18.13.0 255.255.255.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.18.16.0 255.255.255.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.1.192.0 255.255.255.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.1.224.0 255.255.255.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.1.225.0 255.255.255.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.1.226.0 255.255.255.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.1.227.0 255.255.255.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.1.228.0 255.255.255.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.1.229.0 255.255.255.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list nonat extended permit ip 10.1.230.0 255.255.255.0
> > 10.18.15.0
> > 255.255.255.192
> >
> >
> > Two points here.  I defined each as individual /24's to prevent the
> > inclusion of the 10.18.14.0/24 range and so we can add or delete
> easily
> > because we're presently migrating a bit from one 10.x range to
> another.
> > Also, I doubled up the listings 1 for the destination of
> 10.18.14.0/24
> > which
> > is the clients and 10.18.15.0/26 which is a far end site.  Not sure
> if
> > I'm
> > heading in the other direction.  The error I received while trying
to
> > bring
> > up the tunnel is unchanged.  "removing peer failed, no match!"
> >
> > I did grab some debug output from the Pix side here's the important
> bit
> >
> > crypto_isakmp_process_block:src:vpnc, dest:208.x.x.98 spt:500
dpt:500
> > ISAKMP: reserved not zero on payload 5!
> > ISAKMP: malformed payload
> >
> > I assume malformed payload means I have something set incorrectly
> > during the
> > negotiation phase.
> >
> > Any pointers would be appreciated.  I will grab more debug data per
> the
> > other post but this is what I've tried so far.
> >
> > Thanks
> > Scott
> >
> > ----- Original Message -----
> > From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
> > To: "Scott Granados" <gsgranados at comcast.net>
> > Sent: Wednesday, September 02, 2009 11:03 AM
> > Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> >
> >
> > Correct.  But you can have multiple statements in your ACL.
> >
> > Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.15.0
> > 255.255.255.192
> > Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.15.192
> > 255.255.255.192
> > Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.14.0
> > 255.255.255.0
> >
> > And so on.
> >
> > Mike
> >
> > --
> > Michael K. Smith - CISSP, GISP
> > Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
> > w: +1 (206) 404-9500 f: +1 (206) 404-9050
> > PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)
> >
> >
> > -----Original Message-----
> > From: Scott Granados [mailto:gsgranados at comcast.net]
> > Sent: Wednesday, September 02, 2009 11:02 AM
> > To: Michael K. Smith - Adhost; Ryan West; cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> >
> > Hi Michael, thanks but one thing I'm not clear on.
> >
> > Suppose I have destinations of
> > 10.18.15.0/26 10.18.15.192/26 10.18.14.0/24 etc.
> > In other words my possible destinations can be different.  If I use
> > your
> >
> > example what happens if traffic has the proper source but a
> destination
> > of
> > 10.18.15.192/26 or if traffic is destined to a client on
> 10.18.14.0/24?
> > It
> > won't match the ACL correct?
> >
> >
> > ----- Original Message -----
> > From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
> > To: "Scott Granados" <gsgranados at comcast.net>; "Ryan West"
> > <rwest at zyedge.com>; <cisco-nsp at puck.nether.net>
> > Sent: Wednesday, September 02, 2009 10:47 AM
> > Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> >
> >
> > Hi Scott:
> >
> > No, if you use the no-nat below, *all* traffic from 10.18.0.0/24
will
> > not be NAT'd, regardless of the destination.  What you want is:
> >
> > Access-list nonat permit ip 10.18.0.0 255.255.255.0 <remote subnet>
> > <remote mask>
> >
> > In looking at your post below, I think that would be:
> >
> > Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.15.0
> > 255.255.255.192
> >
> > I should note that the mask on the remote side for the 10.18.0.0
> subnet
> > is a /20, not a /24.
> >
> > Regards,
> >
> > Mike
> >
> > --
> > Michael K. Smith - CISSP, GISP
> > Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
> > w: +1 (206) 404-9500 f: +1 (206) 404-9050
> > PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)
> >
> >
> > -----Original Message-----
> > From: Scott Granados [mailto:gsgranados at comcast.net]
> > Sent: Wednesday, September 02, 2009 10:44 AM
> > To: Michael K. Smith - Adhost; Ryan West; cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> >
> > Hi Mike, to follow up on this, I do have existing clients working
> now.
> > For
> > the nonat rule would I create a sepperate ACL for each target or
> would
> > a
> >
> > basic acl like I use for the split tunneling do the trick?
> >
> > either
> > access-list ny-vpn extended permit ip 10.18.0.0 255.255.255.0
> > 10.18.15.0
> >
> > 255.255.255.192
> > or would
> > access-list nonat standard permit 10.18.0.0 255.255.255.0
> >
> > I have several different targets so how would one define that or is
> the
> > standard ACL enough?
> >
> > Thanks for the pointers!
> > Scott
> >
> > ----- Original Message -----
> > From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
> > To: "Scott Granados" <gsgranados at comcast.net>; "Ryan West"
> > <rwest at zyedge.com>; <cisco-nsp at puck.nether.net>
> > Sent: Wednesday, September 02, 2009 10:33 AM
> > Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> >
> >
> > Hello Ryan:
> >
> > Without the no-nat on the ASA side it will try to NAT the traffic
> > before
> > putting it down the tunnel.  So, you're remove side is looking for
> the
> > 10. Addresses, but it's going to see traffic coming from the static
> > outside, NAT'd address.  Thus, the tunnel won't come up because your
> > proposals don't match.
> >
> > Mike
> >
> > --
> > Michael K. Smith - CISSP, GISP
> > Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
> > w: +1 (206) 404-9500 f: +1 (206) 404-9050
> > PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)
> >
> >
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott
> Granados
> > Sent: Wednesday, September 02, 2009 9:45 AM
> > To: Ryan West; cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> >
> > Hi, so right now my Pix in the field is pointing at a VPN 3000 so I
> > can't
> > take that path down until after hours but I will to capture the
debug
> > data.
> >
> > A show ver on the asa shows device manager V5.0.7
> >
> > The field pix shows V6.3
> > I have access to both ends so updating the firmware is definitely an
> > option.
> > Any suggested version?
> >
> > On the ASA side I do not have a no nat statement at all.  I never
> > configured
> > NAT because this device isn't beingused for any features other than
a
> > VPN
> > access device with split tunneling enabled for the clients.
> > On the NY pix side the nat config and acl are as follows.
> >
> > global (outside) 1 208.x.x.100-208.x.x.115 netmask 255.255.255.224
> > global (outside) 1 208.x.x.99 netmask 255.255.255.224
> > nat (inside) 0 access-list vpn-1
> > nat (inside) 1 0.0.0.0 0.0.0.0 0 0
> >
> > access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
> > 255.255.0.0
> > access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
> > 255.255.240.0
> > access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
> > 255.254.0.0
> > access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
> > 255.255.0.0
> > access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
> > 255.255.0.0
> > access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
> > 255.255.0.0
> >
> > Thanks
> > Scott
> >
> > ----- Original Message -----
> > From: "Ryan West" <rwest at zyedge.com>
> > To: "Scott Granados" <gsgranados at comcast.net>;
> > <cisco-nsp at puck.nether.net>
> > Sent: Wednesday, September 02, 2009 6:15 AM
> > Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> >
> >
> > Scott,
> >
> > Can you provide debugs from the ASA, code versions on both devices
> and
> > your
> > associated no-nat ACLs?
> >
> > Assuming you have nothing else logging to monitor, you can enable
> > 'logging
> > class vpn monitor debug' and throw up a term mon to gather inbound
> > messages
> > to the ASA from the PIX side.  You can gather the information on the
> > PIX
> >
> > with a debug cry isa 2 and then initiate interesting traffic from
the
> > ASA
> > using the following, the more valuable information will be on the
> > receiving
> > end.  It really doesn't matter which side you enable as the
receiver,
> > but I
> > try to stay away from pre 7.x code on the PIXes.
> >
> > packet-tracer input inside icmp 10.1.0.10 8 0 10.18.15.10 detailed
> >
> > Phase: 10 or 11 should be subtype encrypt.  If it fails the first
> time,
> > run
> > it again, the negotiation process causes the first packet to fail as
> > the
> >
> > tunnel is being brought.  This type of traffic will also give you
> your
> > debug
> > information and help you figure out where the failure is.
> >
> > -ryan
> >
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott
> Granados
> > Sent: Tuesday, September 01, 2009 8:29 PM
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
> >
> > Hi, I have a Pix out in the field and an ASA5520 that I'm trying to
> > configure to pass L2L traffic.  I keep getting an error that says
> > IKEV1 IP=a.b.c.d removing peer from peer table failed, no match
> > ip=a.b.c.d unable to remove peer table entry
> >
> > What am I doing wrong?
> >
> > Here are the important config bits
> >
> > asa-5520
> > crypto map
> > crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac
> > crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac
> > crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac
> > crypto dynamic-map dynmap 10 set transform-set vpn-transform1
> > vpn-transform2
> > vpn-transform3
> > crypto dynamic-map dynmap 10 set reverse-route
> > crypto map vpn-ra-map 10 match address ny-vpn-acl
> > crypto map vpn-ra-map 10 set peer ny-fw-outside
> > crypto map vpn-ra-map 10 set transform-set vpn-transform2
> > crypto map vpn-ra-map 10 set reverse-route
> > crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap
> > crypto map vpn-ra-map interface outside
> >
> > ISAKMP
> >
> > isakmp enable outside
> > isakmp policy 5 authentication pre-share
> > isakmp policy 5 encryption aes-256
> > isakmp policy 5 hash sha
> > isakmp policy 5 group 7
> > isakmp policy 5 lifetime 3600
> > isakmp policy 10 authentication pre-share
> > isakmp policy 10 encryption aes-256
> > isakmp policy 10 hash sha
> > isakmp policy 10 group 5
> > isakmp policy 10 lifetime 3600
> > isakmp policy 20 authentication pre-share
> > isakmp policy 20 encryption 3des
> > isakmp policy 20 hash sha
> > isakmp policy 20 group 2
> > isakmp policy 20 lifetime 3600
> > isakmp policy 30 authentication pre-share
> > isakmp policy 30 encryption aes-192
> > isakmp policy 30 hash md5
> > isakmp policy 30 group 2
> > isakmp policy 30 lifetime 28800
> > isakmp nat-traversal  20
> > isakmp reload-wait
> >
> > and the acl
> > access-list ny-vpn-acl extended permit ip 10.1.0.0 255.255.0.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list ny-vpn-acl extended permit ip 10.18.0.0 255.255.254.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list ny-vpn-acl extended permit ip 10.14.0.0 255.254.0.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list ny-vpn-acl extended permit ip 157.254.0.0 255.255.0.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list ny-vpn-acl extended permit ip 141.11.0.0 255.255.0.0
> > 10.18.15.0
> > 255.255.255.192
> > access-list ny-vpn-acl extended permit ip 10.11.0.0 255.255.0.0
> > 10.18.15.0
> > 255.255.255.192
> >
> > TUNNEL GROUP
> >
> > tunnel-group 208.37.161.98 type ipsec-l2l
> > tunnel-group 208.37.161.98 general-attributes
> >  tunnel-group 208.37.161.98 ipsec-attributes
> >  pre-shared-key *
> >  peer-id-validate nocheck
> >
> > PIX
> >
> > CRYPTO MAP and ISAKMP
> >
> > crypto ipsec transform-set set1 esp-aes-192 esp-md5-hmac
> > crypto map map1 10 ipsec-isakmp
> > crypto map map1 10 match address vpn-1
> > crypto map map1 10 set peer vpnc
> > crypto map map1 10 set transform-set set1
> > crypto map map1 interface outside
> > isakmp enable outside
> > isakmp key *
> >  address vpnc netmask 255.255.255.255
> > isakmp policy 20 authentication pre-share
> > isakmp policy 20 encryption aes
> > isakmp policy 20 hash sha
> > isakmp policy 20 group 2
> > isakmp policy 20 lifetime 28800
> >
> > ACL
> > access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0
> > 255.255.0.0
> > access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0
> > 255.255.240.0
> > access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0
> > 255.254.0.0
> > access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0
> > 255.255.0.0
> > access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0
> > 255.255.0.0
> > access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0
> > 255.255.0.0
> >
> > )note on the ASA I use individual /24's and shortened the ACL for
> ease
> > of
> > reasing.  I do this to exclued 10.18.14.0/24 from the tunnels since
> > that
> > houses the ASA's inside interface and client access)
> >
> > Any pointers would be appreciated.
> >
> > Thanks
> > Scott
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/


From justin at justinshore.com  Thu Sep  3 15:31:10 2009
From: justin at justinshore.com (Justin Shore)
Date: Thu, 03 Sep 2009 14:31:10 -0500
Subject: [c-nsp] Options for customer prefix injection into iBGP at the edge
Message-ID: <4AA0197E.9010109@justinshore.com>

I'm soliciting suggestions on the pros and cons on the assortment of 
ways to inject customer routes into iBGP at the edge.

One could simply reference prefix-lists in the BGP config on a 
per-neighbor basis (or peer-group).  The downside to this is that 
prefix-lists can't haven't inline comments for storing information about 
the individual prefixes.  As the prefixes on the edge grow I would think 
that admin overhead and potential for errors would grow as well.

I could reference route-maps in the BGP config as well (per 
neighbor/peer-group).  I'm doing this today, matching against a 
prefix-list to get my routes.  The upside is I add a new sequence to the 
route-map per customer and create a uniquely-named prefix-list per 
customer.  This of course requires more config and more potential typos 
but makes changes as customers come and go much more clearcut (ie, there 
is no question which prefixes belong to which customer).  Another upside 
is that I can also put specific communities on prefixes with a 
route-map.  I'm not doing this today but I plan to in the future as my 
BGP community design progresses.

A third option is redistributing statics into BGP.  This gives me the 
opportunity to tag specific prefixes and filter them with a route-map so 
I only redistribute the prefixes that I want redistributed.  I can also 
name static routes.  I need a static route anyway to tack up the route 
for outbound advertisement and to prevent loops.  The downside is that I 
hate using redistribution.  I'm not a big fan of it.  I've been bit too 
many times to consider redistribution a good method of doing anything. 
It will also result in higher CPU load as the RIB is frequently parsed 
for statics and processed with the route-map if I'm not mistaken. 
Correct?

A fourth option would be to use distribute-lists.  I can use remarks to 
label my individual prefixes in the ACL which is good but I end up with 
one large distribute-list ACL for all my customer prefixes.  That means 
any errors could affect all customers at once.  I also don't end up 
using route-maps so I don't get to set communities on advertised prefixes.

And finally I could use a combination of any of the above to accomplish 
my goals.


What methods do my SP colleagues prefer to use when managing the 
injection of customer routes into iBGP?  I'm open to suggestions.  I've 
tried both of the first 2 options and lean towards the 2nd.  It's time I 
get the remaining customer routes out of the IGP but unfortunately I 
can't see far enough ahead to decide which method is best.  I can't help 
but to think that there must be a better way to accomplish my goals 
without increasing my work load too much and without increasing the 
likelihood of making major mistakes.

Thanks
  Justin



From simon at slimey.org  Thu Sep  3 15:32:03 2009
From: simon at slimey.org (Simon Lockhart)
Date: Thu, 3 Sep 2009 20:32:03 +0100
Subject: [c-nsp] HWIC-1ADSL-M
In-Reply-To: <000501ca2cc2$a7dc4a30$f794de90$@co.uk>
References: <000501ca2cc2$a7dc4a30$f794de90$@co.uk>
Message-ID: <20090903193203.GI2898@virtual.bogons.net>

On Thu Sep 03, 2009 at 07:16:27PM +0100, Alex Pimperton wrote:
> Reading through the specs for the above card Cisco mentions not supporting
> "UK Mask".
> 
> Does this mean the card doesn't work for ADSL-M (Seemingly often branded as
> SDSL-M) in the UK?

ADSL and SDSL are two very different things. HWIC-1ADSL-M will do ADSL2+, but
probably not SDSL.

> We're looking at getting some SDSL-M circuits to see what they're like, from
> Spitfire and Nildram (Tiscali), anybody using either HWIC-1ADSL-M or C877-M
> with those providers Annex M services?

We sell ADSL2+ services in the UK using Be/O2 LLU tails, and they have
"approved" bother the HWIC-1ADSL-M and the C877-M for their service. I'm using
a C877-M right now.
 
Simon
-- 
Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration *
   Director    |    * Domain & Web Hosting * Internet Consultancy * 
  Bogons Ltd   | * http://www.bogons.net/  *  Email: info at bogons.net  * 

From drew.weaver at thenap.com  Thu Sep  3 15:32:56 2009
From: drew.weaver at thenap.com (Drew Weaver)
Date: Thu, 3 Sep 2009 15:32:56 -0400
Subject: [c-nsp] IDSM-2 Module VS. TippingPoint VS. Other IDS solutions
Message-ID: <F3318834F1F89D46857972DD4B411D70B0070F8F@EXCHANGE.thenap.com>

Does anyone have any real world experience working with the IDSM-2 modules for the 6500 platform?

I am specifically trying to find people whom have used both the IDSM-2 vs. TippingPoint and even Vs other IDS products...

Any off-list or on-list anecdotes or opinions is highly appreciated.

thanks,
-Drew


From gsgranados at comcast.net  Thu Sep  3 15:51:00 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Thu, 3 Sep 2009 12:51:00 -0700
Subject: [c-nsp] Options for customer prefix injection into iBGP at the
	edge
References: <4AA0197E.9010109@justinshore.com>
Message-ID: <023801ca2ccf$e1a28f60$2208120a@am.thmulti.com>

Hi, so if I were you I'd go with options 1-3 inclusive.

use prefix lists inside route-maps to set the correct community and then 
have route-maps that act on these.  Also redistribute static, connected, etc 
through and use a route-map to set the appropriate communities so something 
like...

ip prefix list not-to-specific seq 5 permit 0.0.0.0/0 le 24

route-map transit1-in permit 10
match ip address prefix-list not-to-specific
set community as:666

or for a customer

ip prefix-list customera seq 5 permit 192.168.0.0/20

route-map customera-in seq 10 permit
match ip address prefix-list customera
set community as:115

You can also add in functions here to prepend your AS on a community tag, 
set local pref, etc.

you would need to then just build your community lists so that they know 
what to do with the various tags (666, no export, 115, announce, etc)

for your redistribution do the same match against your prefix list with your 
CIDR for announcements, against another prefix list which allows for longer 
prefixes for your internals (tag appropriately) and biggity bam you're set.

Tag everything differently for example peering prefixes learned differently 
from transit and use the route-maps to apply the appropriate tag.  This also 
removes the need for network statements in your BGP section and once in 
place greatly simplifies and I think in the end creates less room for fat 
finger errors.  With the different tags you will find it very simple to 
provide customers what ever feed they wish whether it's customers only, 
customers + peers, customers plus peers + transit, full routes, etc.

Thanks
Scott

----- Original Message ----- 
From: "Justin Shore" <justin at justinshore.com>
To: "'Cisco-nsp'" <cisco-nsp at puck.nether.net>
Sent: Thursday, September 03, 2009 12:31 PM
Subject: [c-nsp] Options for customer prefix injection into iBGP at the edge


> I'm soliciting suggestions on the pros and cons on the assortment of ways 
> to inject customer routes into iBGP at the edge.
>
> One could simply reference prefix-lists in the BGP config on a 
> per-neighbor basis (or peer-group).  The downside to this is that 
> prefix-lists can't haven't inline comments for storing information about 
> the individual prefixes.  As the prefixes on the edge grow I would think 
> that admin overhead and potential for errors would grow as well.
>
> I could reference route-maps in the BGP config as well (per 
> neighbor/peer-group).  I'm doing this today, matching against a 
> prefix-list to get my routes.  The upside is I add a new sequence to the 
> route-map per customer and create a uniquely-named prefix-list per 
> customer.  This of course requires more config and more potential typos 
> but makes changes as customers come and go much more clearcut (ie, there 
> is no question which prefixes belong to which customer).  Another upside 
> is that I can also put specific communities on prefixes with a route-map. 
> I'm not doing this today but I plan to in the future as my BGP community 
> design progresses.
>
> A third option is redistributing statics into BGP.  This gives me the 
> opportunity to tag specific prefixes and filter them with a route-map so I 
> only redistribute the prefixes that I want redistributed.  I can also name 
> static routes.  I need a static route anyway to tack up the route for 
> outbound advertisement and to prevent loops.  The downside is that I hate 
> using redistribution.  I'm not a big fan of it.  I've been bit too many 
> times to consider redistribution a good method of doing anything. It will 
> also result in higher CPU load as the RIB is frequently parsed for statics 
> and processed with the route-map if I'm not mistaken. Correct?
>
> A fourth option would be to use distribute-lists.  I can use remarks to 
> label my individual prefixes in the ACL which is good but I end up with 
> one large distribute-list ACL for all my customer prefixes.  That means 
> any errors could affect all customers at once.  I also don't end up using 
> route-maps so I don't get to set communities on advertised prefixes.
>
> And finally I could use a combination of any of the above to accomplish my 
> goals.
>
>
> What methods do my SP colleagues prefer to use when managing the injection 
> of customer routes into iBGP?  I'm open to suggestions.  I've tried both 
> of the first 2 options and lean towards the 2nd.  It's time I get the 
> remaining customer routes out of the IGP but unfortunately I can't see far 
> enough ahead to decide which method is best.  I can't help but to think 
> that there must be a better way to accomplish my goals without increasing 
> my work load too much and without increasing the likelihood of making 
> major mistakes.
>
> Thanks
>  Justin
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From John.Herbert at ins.com  Thu Sep  3 16:58:13 2009
From: John.Herbert at ins.com (John.Herbert at ins.com)
Date: Thu, 3 Sep 2009 15:58:13 -0500
Subject: [c-nsp] BGP multihop between two sites
In-Reply-To: <20090903133422.M65689@fast-serv.com>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>
	<6B43981C32F8464CB24CEE209DA32BD3025171B7@kenya.tronet.as>,
	<20090902204250.M69344@fast-serv.com>
	<3BA4D8A8-4A4D-483A-9B80-9A1524F46062@mimectl>,
	<20090903010632.M90344@fast-serv.com>
	<15407A77-34F6-4B8D-AB41-DE8CBBE3E991@mimectl>
	<20090903133422.M65689@fast-serv.com>
Message-ID: <D11D744DC8FA664CB1FF57683DB37AB30808F7C07E@usemp10.ins.com>

If you generate your BGP routes on your edge router (e.g. redist, network statements), then they would override any eBGP routes you receive from outside. But putting that aside, it would be strongly recommended to filter all local routes so you don't receive them from your upstreams.

You might also want to confirm that your upstreams are not running JunOS facing you - as I mentioned in the thread (URL) I referenced yesterday, I'm told that by default JunOS appears to 'look ahead' and not send routes that would cause an as-path loop, so your allow-as in wouldn't do anything. I have no idea if that's behavior that can be changed, and I'm happy to be schooled by a JunOS guru on that one if I'm wrong.

j.

From: Randy McAnally [mailto:rsm at fast-serv.com]
Sent: Thursday, September 03, 2009 9:38 AM
To: Herbert, John; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] BGP multihop between two sites

No, I think you understand it perfectly.

The goal is to have 'stateful knowledge' of my own eBGP routes, using the simplest most resilient and cross-platform compatible method.

What would be the caveats of the neigbor x.x.x.x allowas-in?  It seems too easy, there HAS to be a catch!  :)

Do I need to change my inbound filters?  Right now I am not filtering inbound routes from the directly connected Tier1's.

--
Randy

---------- Original Message -----------
From: <John.Herbert at ins.com>
To: <rsm at fast-serv.com>, <cisco-nsp at puck.nether.net>
Sent: Wed, 2 Sep 2009 21:42:22 -0500
Subject: RE: [c-nsp] BGP multihop between two sites

> Ah I think I see. Assuming you have no default route learned via eBGP then (given 3 full routing tables, that's probably a fair assumption), the question becomes whether you can intelligently maintain a floating static default based on reachability to the next-hop IP, or if it's better to implement some kind of BGP peering between the two sites.
>
> One possibility might be to consider a conditional static default route - use "ip sla" to test next hop reachability of a provider's router, then use the track command to monitor and apply to a floating default route (and of course, you can do this for more than one provider and provide a predetermined sequence of alternate default routes)
>
> I am not personally a fan of iBGP "raw" over a public network (and that's what it would be since the ASNs are the same on both ends), as most of the protection features in IOS are focused on eBGP. GRE tunnel works, though there may be caveats depending on MTU/fragmentation issues and hardware switching support. Maintaining those BGP peers of course assumes that the remote IP in each case is known in one of the active eBGP sessions at all time. Probably a reasonable assumption if you're using provider-owned IPs to peer; maybe less so if you're using IPs that fall within your own larger block.
>
> I may be misunderstanding something about your particular topology, so my apologies if so.
>
> John.
>
>
________________________________
From: Randy McAnally [rsm at fast-serv.com]
> Sent: Wednesday, September 02, 2009 21:10
> To: Herbert, John; cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] BGP multihop between two sites
>
>
> > I'm not quite clear on the floating default? What is it floating "over"? If you are receiving a default in BGP,
> > then are you / can you receive it from multiple providers for resiliency? And if so, under what circumstances
> >  is the floating static ever active in your routing tables?
>
> It's a high distance static default route in place, to keep packets flowing in case of an eBGP malfunction.  In this case, it was routing packets between locations because the prefixes were not in the routing tables.  This was not discovered until the provider the default pointed went down.
>
> --
> Randy
>
>
>
------- End of Original Message -------

From peter at rathlev.dk  Thu Sep  3 17:34:29 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Thu, 03 Sep 2009 23:34:29 +0200
Subject: [c-nsp] Management stuff in VRFs
In-Reply-To: <C97F73E15F1F0D48A3AC0C423F8C221A01ACD22E@rancor.ad.newedgenetworks.com>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>
	<4A9F7B7E.9030202@renater.fr>
	<C97F73E15F1F0D48A3AC0C423F8C221A01ACD22E@rancor.ad.newedgenetworks.com>
Message-ID: <1252013669.15797.26.camel@abehat.net.rm.dk>

Thank you all for the reponses.

As many replies point out, and as many previous threads bear witness to,
the current implementations of IOS lack full support for a seperate
management VRF. This alone made me curious why people still push in that
direction.

Generally I assume that some kind of OoB management is best practice
already; the typical setup where I'm from is a terminal server of some
kind (e.g. Cisco 2512) in each PoP and some octopus cables reaching out
to all the console ports. This is for emergencies though, not for
"production", i.e. not for Netflow, TACACS+ and so on.

A management network in a seperate VRF will not in itself give anyone
emergency access to devices. I could imagine obscure software bugs that
would actually hinder this access instead. And even though using
seperate physical interfaces is much easier with an isolated VRF it is
not a prerequisite, and without that some of the arguments for the VRF
fall apart IMHO.

Seperating non-business traffic (like Netflow, TACACS+, syslog) from
business traffic is idealogically a good idea. If you extend this
thought we would actually end up with a seperate set of interfaces for
_everything_ which is not customer traffic, including IGP and BGP (and
LDP for those so inclined). Or am I crossing a line here?

And for the record: Yes, poor me, I have no real SP experience, having
only worked with enterprise networks. We use exactly what Donn
describes: A lean global table with all user traffic carried as MPLS.

/Peter

(... off to the purgatory for top posting, sorry. :-))



On Thu, 2009-09-03 at 10:42 -0700, Lasher, Donn wrote:
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jerome Durand
> Subject: Re: [c-nsp] Management stuff in VRFs
> 
> >We went in that direction in our latest deployment and discovered also 
> >that many pieces were missing in IOS and IOS-XR to have full management
> 
> >in a dedicated VRF for all our devices.
> 
> >At this stage we have the VRF but not all management goes there... so 
> >there is more complexity and network is no more secure... I must admit 
> >IOS-XR gives us more troubles as more management features are missing
> in 
> >VRF's.
> 
> The most effective way to do this I've seen so far essentially turns
> your network inside out. The "Global" portion of the router is
> management, in RFC1918 space, and your "internet/public"
> IP's/traffic/etc are all carried in a dedicated VRF.
> 
> Taking a production network NOT designed that way, and doing the
> inside-out... well.... that's every bit as hard as it sounds...



From rdobbins at arbor.net  Thu Sep  3 18:06:33 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Fri, 4 Sep 2009 05:06:33 +0700
Subject: [c-nsp] Management stuff in VRFs
In-Reply-To: <1252013669.15797.26.camel@abehat.net.rm.dk>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>
	<4A9F7B7E.9030202@renater.fr>
	<C97F73E15F1F0D48A3AC0C423F8C221A01ACD22E@rancor.ad.newedgenetworks.com>
	<1252013669.15797.26.camel@abehat.net.rm.dk>
Message-ID: <56E21C26-9D03-45CF-915A-2D631B3B9C72@arbor.net>


On Sep 4, 2009, at 4:34 AM, Peter Rathlev wrote:

> we would actually end up with a seperate set of interfaces for  
> _everything_ which is not customer traffic, including IGP and BGP  
> (and LDP for those so inclined).

Divorcing the control plane from dependence upon the data plane would  
be a huge win in terms of security/availability.  It's unfortunate  
that the routing protocols currently in use weren't designed for this  
mode of operation from the start.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

Sorry, sometimes I mistake your existential crises for technical
insights.

			-- xkcd #625


From lodwijk2009 at gmail.com  Thu Sep  3 21:35:37 2009
From: lodwijk2009 at gmail.com (lodwijk hutapea)
Date: Thu, 3 Sep 2009 18:35:37 -0700
Subject: [c-nsp] (no subject)
Message-ID: <a82d3d4c0909031835g249ee18fob86288b20a7a8167@mail.gmail.com>



From mtinka at globaltransit.net  Thu Sep  3 20:08:12 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Fri, 4 Sep 2009 08:08:12 +0800
Subject: [c-nsp] slow down VTY speed
In-Reply-To: <255433.5131.qm@web110109.mail.gq1.yahoo.com>
References: <255433.5131.qm@web110109.mail.gq1.yahoo.com>
Message-ID: <200909040808.22379.mtinka@globaltransit.net>

On Wednesday 02 September 2009 03:04:55 pm Tony wrote:

> One thing that I've just discovered that puzzles me is
> that the OSPF neighbour drops are only on ONE of the
> links that come into this 7204. It has neighbours on the
> interfaces Fa0/0.3, Atm1/0.2 & Atm1/0..3. It is only the
> neighbour on the Fa0/0.3 interface that is dropping, the
> two connected via ATM are not dropping at all. Is there
> any logical reason for this ? Is it because I'm using the
> 10/100 port on the I/O module ? Would it be any different
> if the ethernet interface was on a PA instead ?

During the transient CPU spike we saw when we re-inserted 
compact flash drives into an NPE-G2's or NPE-G1's, BFD 
complained only on one of the interfaces, as well (as I 
alluded to in a previous post on this list where the OP was 
suffering some USB madness).

We found it curious that it happened on only one of the 
links (both are Gig-E off the NPE-G1/2), but for a number of 
reasons, haven't looked into it 
any further.

Of course, Graceful Restart for IS-IS and LDP was enabled, 
plus the other link was unaffected, so the data plane didn't 
hurt.

Cheers,

Mark.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090904/49f29348/attachment-0001.bin>

From alex at erus.co.uk  Fri Sep  4 03:38:11 2009
From: alex at erus.co.uk (Alex Pimperton)
Date: Fri, 4 Sep 2009 08:38:11 +0100
Subject: [c-nsp]  HWIC-1ADSL-M
Message-ID: <000601ca2d32$a7f55b90$f7e012b0$@co.uk>

> On Thu Sep 03, 2009 at 07:16:27PM +0100, Alex Pimperton wrote:
> > Reading through the specs for the above card Cisco mentions not
> supporting
> > "UK Mask".
> >
> > Does this mean the card doesn't work for ADSL-M (Seemingly often
> branded as
> > SDSL-M) in the UK?
>
> ADSL and SDSL are two very different things. HWIC-1ADSL-M will do
> ADSL2+, but
> probably not SDSL.

I'm aware that it's ADSL 2+ underneath but some providers (Spitfire,
Nildram) are marketing their ADSL Annex-M products as "SDSL (M)", presumably
because of the symmetrical upload/download, and the fact that it sounds like
SDSL, which business are already familiar with.

> 
> > We're looking at getting some SDSL-M circuits to see what they're
> like, from
> > Spitfire and Nildram (Tiscali), anybody using either HWIC-1ADSL-M or
> C877-M
> > with those providers Annex M services?
> 
> We sell ADSL2+ services in the UK using Be/O2 LLU tails, and they have
> "approved" bother the HWIC-1ADSL-M and the C877-M for their service.
> I'm using
> a C877-M right now.

Thanks Simon, I saw mention of the C877-M on the BE UserGroup website but no
specific mention of Annex-M products on the (colourful) BE website.

Anybody else using Cisco kit at the end of an Annex-M tail from another
provider?

Cheers,

Alex




-- 
This message has been scanned for viruses and
dangerous content by AxTech, and is
believed to be clean.


From jdurand at renater.fr  Fri Sep  4 04:46:30 2009
From: jdurand at renater.fr (Jerome Durand)
Date: Fri, 04 Sep 2009 10:46:30 +0200
Subject: [c-nsp] Management stuff in VRFs
In-Reply-To: <C97F73E15F1F0D48A3AC0C423F8C221A01ACD22E@rancor.ad.newedgenetworks.com>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>	<4A9F7B7E.9030202@renater.fr>
	<C97F73E15F1F0D48A3AC0C423F8C221A01ACD22E@rancor.ad.newedgenetworks.com>
Message-ID: <4AA0D3E6.6000508@renater.fr>

> The most effective way to do this I've seen so far essentially turns
> your network inside out. The "Global" portion of the router is
> management, in RFC1918 space, and your "internet/public"
> IP's/traffic/etc are all carried in a dedicated VRF.

And there multicast (IPv4 and IPv6) came in ;)

Jerome

> Taking a production network NOT designed that way, and doing the
> inside-out... well.... that's every bit as hard as it sounds...
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
-------------------------------------------------------------
Jerome Durand

Responsable des services aux usagers
Services operations & support manager

             R?seau National de T?l?communications
      pour la Technologie, l'Enseignement et la Recherche

Tel:    +33 (0) 1 53 94 20 40  |  GIP RENATER
Fax:    +33 (0) 1 53 94 20 41  |  c/o ENSAM
E-mail: jdurand at renater.fr     |  151 Boulevard de l'H?pital
http://www.renater.fr          |  75013 PARIS
--------------------------------------------------------------


From morten at skriver.dk  Fri Sep  4 04:17:55 2009
From: morten at skriver.dk (Morten Skriver)
Date: Fri, 4 Sep 2009 10:17:55 +0200
Subject: [c-nsp] instabilities with SXI2?
In-Reply-To: <20090901085317.GC2951@lboro.ac.uk>
References: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>
	<4A9CDB6A.6080607@imperial.ac.uk>
	<20090901085317.GC2951@lboro.ac.uk>
Message-ID: <20090904081755.GO20558@skriver.dk>

On Tue, Sep 01, 2009 at 09:53:17AM +0100, Alan Buxey wrote:

> > FWIW we just ran into this; TAC told me SXI2a would be released
> > "shortly"
> 
> shortly, as in reasonably rapidly/soon .... or like SXI3 - in October?

12.2(33)SXI2a was released on cisco.com yesterday.

/Morten

-- 
Morten Skriver, morten(at)skriver(dot)dk  -  CCIE #15804

From Grzegorz at Janoszka.pl  Fri Sep  4 05:21:36 2009
From: Grzegorz at Janoszka.pl (Grzegorz Janoszka)
Date: Fri, 04 Sep 2009 11:21:36 +0200
Subject: [c-nsp] instabilities with SXI2?
In-Reply-To: <20090904081755.GO20558@skriver.dk>
References: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>	<4A9CDB6A.6080607@imperial.ac.uk>	<20090901085317.GC2951@lboro.ac.uk>
	<20090904081755.GO20558@skriver.dk>
Message-ID: <4AA0DC20.9040703@Janoszka.pl>

Morten Skriver wrote
> 12.2(33)SXI2a was released on cisco.com yesterday.

Yes, I saw it yesterday, but does anyone know what they changed/fixed/broke?

http://www.ciscopaw.org/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/ol_14271.html 
does not mention SXI2a.

-- 
Grzegorz Janoszka

From tomas at soitron.com  Fri Sep  4 08:13:28 2009
From: tomas at soitron.com (Daniska, Tomas)
Date: Fri, 4 Sep 2009 14:13:28 +0200
Subject: [c-nsp] instabilities with SXI2?
In-Reply-To: <4AA0DC20.9040703@Janoszka.pl>
References: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>	<4A9CDB6A.6080607@imperial.ac.uk>	<20090901085317.GC2951@lboro.ac.uk>
	<20090904081755.GO20558@skriver.dk> <4AA0DC20.9040703@Janoszka.pl>
Message-ID: <6B43981C32F8464CB24CEE209DA32BD3025174CB@kenya.tronet.as>


> -----Original Message-----
> 
> Morten Skriver wrote
> > 12.2(33)SXI2a was released on cisco.com yesterday.
> 
> Yes, I saw it yesterday, but does anyone know what they
> changed/fixed/broke?
> 
>
http://www.ciscopaw.org/en/US/docs/switches/lan/catalyst6500/ios/12.2SX
> /release/notes/ol_14271.html
> does not mention SXI2a.

I've tried getting at least informal release notes from the BU through
our local team but no success so far

--

deejay

 

__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4391
(20090903) __________

Tuto spravu preveril ESET NOD32 Antivirus.

http://www.eset.sk
 

From chris at lavin-llc.com  Fri Sep  4 08:42:22 2009
From: chris at lavin-llc.com (chris at lavin-llc.com)
Date: Fri, 04 Sep 2009 08:42:22 -0400
Subject: [c-nsp] Options for customer prefix injection into iBGP at the
	edge
Message-ID: <40527.1252068142@lavin-llc.com>

On Thu Sep  3 15:31 , Justin Shore  sent:

>I'm soliciting suggestions on the pros and cons on the assortment of 
>ways to inject customer routes into iBGP at the edge.
>
>One could simply reference prefix-lists in the BGP config on a 
>per-neighbor basis (or peer-group).  The downside to this is that 
>prefix-lists can't haven't inline comments for storing information about 
>the individual prefixes.  As the prefixes on the edge grow I would think 
>that admin overhead and potential for errors would grow as well.
>
>I could reference route-maps in the BGP config as well (per 
>neighbor/peer-group).  I'm doing this today, matching against a 
>prefix-list to get my routes.  The upside is I add a new sequence to the 
>route-map per customer and create a uniquely-named prefix-list per 
>customer.  This of course requires more config and more potential typos 
>but makes changes as customers come and go much more clearcut (ie, there 
>is no question which prefixes belong to which customer).  Another upside 
>is that I can also put specific communities on prefixes with a 
>route-map.  I'm not doing this today but I plan to in the future as my 
>BGP community design progresses.

I prefer using your second option. Whether in an ISP (with customer routes) or a large enterprise (with lots of business partners), I like the use of 
prefix-list for the exact reason you stated; labeled by customer/business partner name, route-maps (ditto; labeled by customer/business partner name). 
This gives you alot of flexibility to tag or influence behavior and policy by altering options within the route-map for both incoming and outgoing 
routing policies. I think this format also makes it easier on your operations folks since you've named the prefix-lists and route-maps associated with 
each customer/business partner.

-chris


>
>A third option is redistributing statics into BGP.  This gives me the 
>opportunity to tag specific prefixes and filter them with a route-map so 
>I only redistribute the prefixes that I want redistributed.  I can also 
>name static routes.  I need a static route anyway to tack up the route 
>for outbound advertisement and to prevent loops.  The downside is that I 
>hate using redistribution.  I'm not a big fan of it.  I've been bit too 
>many times to consider redistribution a good method of doing anything. 
>It will also result in higher CPU load as the RIB is frequently parsed 
>for statics and processed with the route-map if I'm not mistaken. 
>Correct?
>
>A fourth option would be to use distribute-lists.  I can use remarks to 
>label my individual prefixes in the ACL which is good but I end up with 
>one large distribute-list ACL for all my customer prefixes.  That means 
>any errors could affect all customers at once.  I also don't end up 
>using route-maps so I don't get to set communities on advertised prefixes.
>
>And finally I could use a combination of any of the above to accomplish 
>my goals.
>
>
>What methods do my SP colleagues prefer to use when managing the 
>injection of customer routes into iBGP?  I'm open to suggestions.  I've 
>tried both of the first 2 options and lean towards the 2nd.  It's time I 
>get the remaining customer routes out of the IGP but unfortunately I 
>can't see far enough ahead to decide which method is best.  I can't help 
>but to think that there must be a better way to accomplish my goals 
>without increasing my work load too much and without increasing the 
>likelihood of making major mistakes.
>
>Thanks
>  Justin
>
>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/



From rodunn at cisco.com  Fri Sep  4 10:00:04 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Fri, 04 Sep 2009 10:00:04 -0400
Subject: [c-nsp] instabilities with SXI2?
In-Reply-To: <6B43981C32F8464CB24CEE209DA32BD3025174CB@kenya.tronet.as>
References: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>	<4A9CDB6A.6080607@imperial.ac.uk>	<20090901085317.GC2951@lboro.ac.uk>	<20090904081755.GO20558@skriver.dk>
	<4AA0DC20.9040703@Janoszka.pl>
	<6B43981C32F8464CB24CEE209DA32BD3025174CB@kenya.tronet.as>
Message-ID: <4AA11D64.1060800@cisco.com>

There are only 4 fixes in it.

CSCtb15569    VPN-SPA - traffic failed to decrypt due to SecInfo check 
failure

CSCtb27643    cat6000 Medium buffers leak on SP leading to crash

CSCsu65967    Modular IOS crash at free_lite_internal

And the 4th was just an ISSU matrix creation change.

Rodney



Daniska, Tomas wrote:
>> -----Original Message-----
>>
>> Morten Skriver wrote
>>> 12.2(33)SXI2a was released on cisco.com yesterday.
>> Yes, I saw it yesterday, but does anyone know what they
>> changed/fixed/broke?
>>
>>
> http://www.ciscopaw.org/en/US/docs/switches/lan/catalyst6500/ios/12.2SX
>> /release/notes/ol_14271.html
>> does not mention SXI2a.
> 
> I've tried getting at least informal release notes from the BU through
> our local team but no success so far
> 
> --
> 
> deejay
> 
>  
> 
> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 4391
> (20090903) __________
> 
> Tuto spravu preveril ESET NOD32 Antivirus.
> 
> http://www.eset.sk
>  
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From peter at rathlev.dk  Fri Sep  4 10:56:13 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Fri, 04 Sep 2009 16:56:13 +0200
Subject: [c-nsp] srr-queue bandwidth share on 3750
In-Reply-To: <dd3e48e0908311333p36e40011n311590b26b0a2542@mail.gmail.com>
References: <dd3e48e0908311333p36e40011n311590b26b0a2542@mail.gmail.com>
Message-ID: <1252076173.3237.8.camel@abehat.net.rm.dk>

On Mon, 2009-08-31 at 16:33 -0400, samuel vuillaume wrote:
...
>  srr-queue bandwidth share 1 59 30 10
...
> In case of congestion, let's say my queue 2 is free of use
> (empty) .... How are my queues 3 and 4 gonna to use the free queue
> bandwidth queue 2? i mean, with this configuration my queue 2,3 and 4
> get the remaining bandwidth after the queue 1:
> 
> queue 2, 59/99*66Mps = 39 Mbps
> queue 3, 20Mbps
> queue 4, 6Mps
> 
> so it means 39 Mpbs available to allocate to queue 3 and Queue 4...
> how ths traffic will be shared between 3 and 4? ( i suppose it's
> related to the priority of the queue)

They will share, but not equally. Queue 3 will take 75% of the remaining
bandwidth, queue 4 will take 25%. If any queue does not use it's
allocated amount (either because it uses a shaping SRR instead or
because there are no packets) the allocation is simple disregarded.

You can view the SRR sharing algo as:

1) take W1 packets from queue 1 (=> 0, shaping)
2) take W2 packets from queue 2 (=> 0, queue empty)
3) take W3 packets from queue 3 (=> 30 if they're there)
4) take W4 packets from queue 4 (=> 10 if they're there)
5) repeat from step 1)

So each round of 40 packets takes 30 from Q3 and 10 from Q4.

-- 
Peter



From jp at saucer.midcoast.com  Fri Sep  4 11:29:48 2009
From: jp at saucer.midcoast.com (jp)
Date: Fri, 4 Sep 2009 11:29:48 -0400
Subject: [c-nsp] OT - Dark Fiber
In-Reply-To: <48593.1251916052@lavin-llc.com>
References: <48593.1251916052@lavin-llc.com>
Message-ID: <20090904152948.GA8726@saucer.midcoast.com>

We are an ISP and lease fiber from other ISP/CLECs and an independent 
phone company/CLEC. We have also strung fiber ourselves for short 
distances with property owner approval. The fiber "owner" has to pay 
municipal taxes and pole rental fees, and construction can be expensive, 
so expect to have both MRC and NRC, unless the NRC is amortized into the 
MRC. The local bell is almost always cost prohibitive or unavailable 
unless you a re CLEC and then "almost always" changes to "likely".

Regarding the topic... If someone provides dark fiber, would they be 
subject to CALEA requirements to be able to tap and record the 
transmission? As an ISP, I know the LEAs would come to me rather than 
the fiber provider, so that has never been a concern to my fiber 
providers that I know of. How do providers of dark fiber handle 
non-ISP/Telecom customers with regards to CALEA compliance capabilities?

On Wed, Sep 02, 2009 at 02:27:32PM -0400, chris at lavin-llc.com wrote:
> I was curious to know if there are different ways to go about 
> purchasing dark fiber. If you have Site A and Site B only a few miles 
> apart and you're happy to provide the light, how do you get the fiber? 
> Not expecting to obtain right-of-way/permits/ditch digger. Do you 
> lease (meaning paying a MRC) or is it 'purchased' (meaning a NRC)?
> 
> Thanks,
> -chris
> 
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
/*
Jason Philbrook   |   Midcoast Internet Solutions - Wireless and DSL
    KB1IOJ        |   Broadband Internet Access, Dialup, and Hosting 
 http://f64.nu/   |   for Midcoast Maine    http://www.midcoast.com/
*/

From fasterfourier at gmail.com  Fri Sep  4 12:31:21 2009
From: fasterfourier at gmail.com (Robert Johnson)
Date: Fri, 4 Sep 2009 12:31:21 -0400
Subject: [c-nsp] Router on a stick with multiple bridged interfaces
Message-ID: <4f84a6f80909040931g4148b380hcb4dfd8ab34eff1@mail.gmail.com>

Hello Cisco experts,
Here's today's question. I have a simple router on a stick with a
fastethernet interface and multiple 802.1Q subinterfaces connected to a
layer 2 switchport in trunk mode. Now say I want to add another switch with
the same group of VLANs as the first switch, bridged to the first switch.
Instead of connecting the new switch to a trunk port on the existing switch,
I'd like to attach it to a router interface. So essentially I want two
router interfaces that are transparently bridged, with the ability to attach
routed 802.1Q subinterfaces to both interfaces simultaneously.

What's the best way to do this?

Robert

From bgoulet at harris.com  Fri Sep  4 13:02:28 2009
From: bgoulet at harris.com (Goulet, Brian)
Date: Fri, 4 Sep 2009 13:02:28 -0400
Subject: [c-nsp] slow down VTY speed
In-Reply-To: <mailman.322.1252048105.2225.cisco-nsp@puck.nether.net>
References: <mailman.322.1252048105.2225.cisco-nsp@puck.nether.net>
Message-ID: <290EF89F13F04F4E924BB235A46D18F1906802@MLBMXUS2.cs.myharris.net>


On Wednesday 02 September 2009 03:04:55 pm Tony wrote:

> One thing that I've just discovered that puzzles me is
> that the OSPF neighbour drops are only on ONE of the
> links that come into this 7204. It has neighbours on the
> interfaces Fa0/0.3, Atm1/0.2 & Atm1/0..3. It is only the
> neighbour on the Fa0/0.3 interface that is dropping, the
> two connected via ATM are not dropping at all. Is there
> any logical reason for this ? Is it because I'm using the
> 10/100 port on the I/O module ? Would it be any different
> if the ethernet interface was on a PA instead ? 

Not sure if anyone answered this.  Check the hello timers for the interfaces.  As I recall, ethernet interfaces default to a shorter hello/dead interval than do ATM/frame relay/etc.  Longer timer intervals on your ATM interfaces could account for their neighbor relationships being more resilient in the face of adversity.

Brian 

From jay at west.net  Fri Sep  4 13:14:18 2009
From: jay at west.net (Jay Hennigan)
Date: Fri, 04 Sep 2009 10:14:18 -0700
Subject: [c-nsp] Router on a stick with multiple bridged interfaces
In-Reply-To: <4f84a6f80909040931g4148b380hcb4dfd8ab34eff1@mail.gmail.com>
References: <4f84a6f80909040931g4148b380hcb4dfd8ab34eff1@mail.gmail.com>
Message-ID: <4AA14AEA.4050306@west.net>

Robert Johnson wrote:
> Hello Cisco experts,
> Here's today's question. I have a simple router on a stick with a
> fastethernet interface and multiple 802.1Q subinterfaces connected to a
> layer 2 switchport in trunk mode. Now say I want to add another switch with
> the same group of VLANs as the first switch, bridged to the first switch.
> Instead of connecting the new switch to a trunk port on the existing switch,
> I'd like to attach it to a router interface. So essentially I want two
> router interfaces that are transparently bridged, with the ability to attach
> routed 802.1Q subinterfaces to both interfaces simultaneously.
> 
> What's the best way to do this?

Turn on IRB in the router.
Configure a bridge group for each VLAN.
Remove the IP configuration from the dot1q subinterfaces.
Add the IP configuration to the BVI for each VLAN.
Assign the subinterfaces to the appropriate bridge groups on both 
physical interfaces.

Consider possible spanning tree issues should someone bridge VLANs the 
two switches accidentally or if you want to intentionally trunk between 
them for interface redundancy.

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

From drais at icantclick.org  Fri Sep  4 15:40:12 2009
From: drais at icantclick.org (david raistrick)
Date: Fri, 4 Sep 2009 15:40:12 -0400 (EDT)
Subject: [c-nsp] OT - Dark Fiber
In-Reply-To: <20090904152948.GA8726@saucer.midcoast.com>
References: <48593.1251916052@lavin-llc.com>
	<20090904152948.GA8726@saucer.midcoast.com>
Message-ID: <alpine.BSF.2.00.0909041538060.69948@murf.icantclick.org>

On Fri, 4 Sep 2009, jp wrote:

> Regarding the topic... If someone provides dark fiber, would they be
> subject to CALEA requirements to be able to tap and record the

I haven't followed CALEA-for-ISPs for a few years, but at least when it 
was initially required, dark fiber providers won't need to comply with 
CALEA.  They're not providing network service.   -lit- fiber providers 
would because they're either providing network or telecom service....but 
they generally wouldn't do it at the physical layer.

...david

--
david raistrick        http://www.netmeister.org/news/learn2quote.html
drais at icantclick.org             http://www.expita.com/nomime.html


From frnkblk at iname.com  Fri Sep  4 16:05:01 2009
From: frnkblk at iname.com (Frank Bulk - iName.com)
Date: Fri, 4 Sep 2009 15:05:01 -0500
Subject: [c-nsp] Management stuff in VRFs
In-Reply-To: <1252013669.15797.26.camel@abehat.net.rm.dk>
References: <1251920188.2923.4.camel@abehat.net.rm.dk>	<4A9F7B7E.9030202@renater.fr>	<C97F73E15F1F0D48A3AC0C423F8C221A01ACD22E@rancor.ad.newedgenetworks.com>
	<1252013669.15797.26.camel@abehat.net.rm.dk>
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAB+WGnNTiwST6epD7SCZdpEAQAAAAA=@iname.com>

In short, the best management VRF is a serial-based terminal server. =)

Frank

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Rathlev
Sent: Thursday, September 03, 2009 4:34 PM
To: cisco-nsp
Subject: Re: [c-nsp] Management stuff in VRFs

Thank you all for the reponses.

As many replies point out, and as many previous threads bear witness to,
the current implementations of IOS lack full support for a seperate
management VRF. This alone made me curious why people still push in that
direction.

Generally I assume that some kind of OoB management is best practice
already; the typical setup where I'm from is a terminal server of some
kind (e.g. Cisco 2512) in each PoP and some octopus cables reaching out
to all the console ports. This is for emergencies though, not for
"production", i.e. not for Netflow, TACACS+ and so on.

A management network in a seperate VRF will not in itself give anyone
emergency access to devices. I could imagine obscure software bugs that
would actually hinder this access instead. And even though using
seperate physical interfaces is much easier with an isolated VRF it is
not a prerequisite, and without that some of the arguments for the VRF
fall apart IMHO.

Seperating non-business traffic (like Netflow, TACACS+, syslog) from
business traffic is idealogically a good idea. If you extend this
thought we would actually end up with a seperate set of interfaces for
_everything_ which is not customer traffic, including IGP and BGP (and
LDP for those so inclined). Or am I crossing a line here?

And for the record: Yes, poor me, I have no real SP experience, having
only worked with enterprise networks. We use exactly what Donn
describes: A lean global table with all user traffic carried as MPLS.

/Peter

(... off to the purgatory for top posting, sorry. :-))



On Thu, 2009-09-03 at 10:42 -0700, Lasher, Donn wrote:
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jerome Durand
> Subject: Re: [c-nsp] Management stuff in VRFs
> 
> >We went in that direction in our latest deployment and discovered also 
> >that many pieces were missing in IOS and IOS-XR to have full management
> 
> >in a dedicated VRF for all our devices.
> 
> >At this stage we have the VRF but not all management goes there... so 
> >there is more complexity and network is no more secure... I must admit 
> >IOS-XR gives us more troubles as more management features are missing
> in 
> >VRF's.
> 
> The most effective way to do this I've seen so far essentially turns
> your network inside out. The "Global" portion of the router is
> management, in RFC1918 space, and your "internet/public"
> IP's/traffic/etc are all carried in a dedicated VRF.
> 
> Taking a production network NOT designed that way, and doing the
> inside-out... well.... that's every bit as hard as it sounds...


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From gsgranados at comcast.net  Fri Sep  4 16:07:36 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Fri, 4 Sep 2009 13:07:36 -0700
Subject: [c-nsp] CALEA was Re:  OT - Dark Fiber
References: <48593.1251916052@lavin-llc.com><20090904152948.GA8726@saucer.midcoast.com>
	<alpine.BSF.2.00.0909041538060.69948@murf.icantclick.org>
Message-ID: <02ae01ca2d9b$5fde85c0$2208120a@am.thmulti.com>

Why does anyone comply with CALEA?  Especially after the abuses of the last 
8 years and probably a lot farther back than that?  I've been reading about 
the requirements and the idea that ISPs cooperate with law enforcement 
really makes me uneasy on a civil liberties basis. Does Uncle Sam scare 
tactic people in to compliance?  There's just something about making things 
easier for the NSA and any number of alphabet soup agencies that strikes me 
as unamerican (to use their own phrase against them) and wrong. Or was it 
created simply to create a new space for security products and C, J and the 
others were really good at lobbying?
    Since it doesn't require the ISP to break open encrypted traffic it 
almost makes me think a public key system that lets the end user encrypt 
everything from phone to television with their own keys makes some sense so 
there's nothing left in the clear for entertaining the James Bond crowd! 
Probably not practical at all but this thread just convinced me not to use 
split tunneling.;)

----- Original Message ----- 
From: "david raistrick" <drais at icantclick.org>
To: "jp" <jp at saucer.midcoast.com>
Cc: <cisco-nsp at puck.nether.net>
Sent: Friday, September 04, 2009 12:40 PM
Subject: Re: [c-nsp] OT - Dark Fiber


> On Fri, 4 Sep 2009, jp wrote:
>
>> Regarding the topic... If someone provides dark fiber, would they be
>> subject to CALEA requirements to be able to tap and record the
>
> I haven't followed CALEA-for-ISPs for a few years, but at least when it 
> was initially required, dark fiber providers won't need to comply with 
> CALEA.  They're not providing network service.   -lit- fiber providers 
> would because they're either providing network or telecom service....but 
> they generally wouldn't do it at the physical layer.
>
> ...david
>
> --
> david raistrick        http://www.netmeister.org/news/learn2quote.html
> drais at icantclick.org             http://www.expita.com/nomime.html
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From gsgranados at comcast.net  Fri Sep  4 16:18:44 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Fri, 4 Sep 2009 13:18:44 -0700
Subject: [c-nsp] Management stuff in VRFs
References: <1251920188.2923.4.camel@abehat.net.rm.dk>	<4A9F7B7E.9030202@renater.fr>	<C97F73E15F1F0D48A3AC0C423F8C221A01ACD22E@rancor.ad.newedgenetworks.com><1252013669.15797.26.camel@abehat.net.rm.dk>
	<!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAB+WGnNTiwST6epD7SCZdpEAQAAAAA=@iname.com>
Message-ID: <02bc01ca2d9c$ed919690$2208120a@am.thmulti.com>

Hi, just to add to this...

I have to strongly support the out of band management angle.  If designed 
properly you can carry all your management traffic including provisioning 
and authentication as well as provide emergency access.  A simple setup with 
T1's and 25xx / 26xx boxes with the octopus cables should do the trick. 
Aggregate them over a reasonable sized geographic area to an aggregation 
core and Bob's your uncle.  When you see DS1 loop pricing in some markets 
sub $40 per it seems worth it instead of dealing with the headaches and lack 
of functionality of inband management.

----- Original Message ----- 
From: "Frank Bulk - iName.com" <frnkblk at iname.com>
To: "'Peter Rathlev'" <peter at rathlev.dk>; "cisco-nsp" 
<cisco-nsp at puck.nether.net>
Sent: Friday, September 04, 2009 1:05 PM
Subject: Re: [c-nsp] Management stuff in VRFs


> In short, the best management VRF is a serial-based terminal server. =)
>
> Frank
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Rathlev
> Sent: Thursday, September 03, 2009 4:34 PM
> To: cisco-nsp
> Subject: Re: [c-nsp] Management stuff in VRFs
>
> Thank you all for the reponses.
>
> As many replies point out, and as many previous threads bear witness to,
> the current implementations of IOS lack full support for a seperate
> management VRF. This alone made me curious why people still push in that
> direction.
>
> Generally I assume that some kind of OoB management is best practice
> already; the typical setup where I'm from is a terminal server of some
> kind (e.g. Cisco 2512) in each PoP and some octopus cables reaching out
> to all the console ports. This is for emergencies though, not for
> "production", i.e. not for Netflow, TACACS+ and so on.
>
> A management network in a seperate VRF will not in itself give anyone
> emergency access to devices. I could imagine obscure software bugs that
> would actually hinder this access instead. And even though using
> seperate physical interfaces is much easier with an isolated VRF it is
> not a prerequisite, and without that some of the arguments for the VRF
> fall apart IMHO.
>
> Seperating non-business traffic (like Netflow, TACACS+, syslog) from
> business traffic is idealogically a good idea. If you extend this
> thought we would actually end up with a seperate set of interfaces for
> _everything_ which is not customer traffic, including IGP and BGP (and
> LDP for those so inclined). Or am I crossing a line here?
>
> And for the record: Yes, poor me, I have no real SP experience, having
> only worked with enterprise networks. We use exactly what Donn
> describes: A lean global table with all user traffic carried as MPLS.
>
> /Peter
>
> (... off to the purgatory for top posting, sorry. :-))
>
>
>
> On Thu, 2009-09-03 at 10:42 -0700, Lasher, Donn wrote:
>> -----Original Message-----
>> From: cisco-nsp-bounces at puck.nether.net
>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jerome Durand
>> Subject: Re: [c-nsp] Management stuff in VRFs
>>
>> >We went in that direction in our latest deployment and discovered also
>> >that many pieces were missing in IOS and IOS-XR to have full management
>>
>> >in a dedicated VRF for all our devices.
>>
>> >At this stage we have the VRF but not all management goes there... so
>> >there is more complexity and network is no more secure... I must admit
>> >IOS-XR gives us more troubles as more management features are missing
>> in
>> >VRF's.
>>
>> The most effective way to do this I've seen so far essentially turns
>> your network inside out. The "Global" portion of the router is
>> management, in RFC1918 space, and your "internet/public"
>> IP's/traffic/etc are all carried in a dedicated VRF.
>>
>> Taking a production network NOT designed that way, and doing the
>> inside-out... well.... that's every bit as hard as it sounds...
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From jared at puck.nether.net  Fri Sep  4 16:19:52 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 4 Sep 2009 16:19:52 -0400
Subject: [c-nsp] CALEA was Re:  OT - Dark Fiber
In-Reply-To: <02ae01ca2d9b$5fde85c0$2208120a@am.thmulti.com>
References: <48593.1251916052@lavin-llc.com><20090904152948.GA8726@saucer.midcoast.com>
	<alpine.BSF.2.00.0909041538060.69948@murf.icantclick.org>
	<02ae01ca2d9b$5fde85c0$2208120a@am.thmulti.com>
Message-ID: <3DBA1CBE-560F-4D77-B04A-B945320A0422@puck.nether.net>

Talk to your counsel about the compliance requests you get. You may be  
able to get away without it, but you are required to comply with any  
lawful requests, even if you don't like them. The same is true for any  
business where you could get a lawful request for records.

Check out packetforensics if you need a device, much cheaper than  
others in the space, their website can be a bit funny, but worth  
having a [free] login.

- Jared

On Sep 4, 2009, at 4:07 PM, Scott Granados wrote:

> Why does anyone comply with CALEA?  Especially after the abuses of  
> the last 8 years and probably a lot farther back than that?  I've  
> been reading about the requirements and the idea that ISPs cooperate  
> with law enforcement really makes me uneasy on a civil liberties  
> basis. Does Uncle Sam scare tactic people in to compliance?  There's  
> just something about making things easier for the NSA and any number  
> of alphabet soup agencies that strikes me as unamerican (to use  
> their own phrase against them) and wrong. Or was it created simply  
> to create a new space for security products and C, J and the others  
> were really good at lobbying?
>   Since it doesn't require the ISP to break open encrypted traffic  
> it almost makes me think a public key system that lets the end user  
> encrypt everything from phone to television with their own keys  
> makes some sense so there's nothing left in the clear for  
> entertaining the James Bond crowd! Probably not practical at all but  
> this thread just convinced me not to use split tunneling.;)
>
> ----- Original Message ----- From: "david raistrick" <drais at icantclick.org 
> >
> To: "jp" <jp at saucer.midcoast.com>
> Cc: <cisco-nsp at puck.nether.net>
> Sent: Friday, September 04, 2009 12:40 PM
> Subject: Re: [c-nsp] OT - Dark Fiber
>
>
>> On Fri, 4 Sep 2009, jp wrote:
>>
>>> Regarding the topic... If someone provides dark fiber, would they be
>>> subject to CALEA requirements to be able to tap and record the
>>
>> I haven't followed CALEA-for-ISPs for a few years, but at least  
>> when it was initially required, dark fiber providers won't need to  
>> comply with CALEA.  They're not providing network service.   -lit-  
>> fiber providers would because they're either providing network or  
>> telecom service....but they generally wouldn't do it at the  
>> physical layer.
>>
>> ...david
>>
>> --
>> david raistrick        http://www.netmeister.org/news/ 
>> learn2quote.html
>> drais at icantclick.org             http://www.expita.com/nomime.html
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From gsgranados at comcast.net  Fri Sep  4 16:29:16 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Fri, 4 Sep 2009 13:29:16 -0700
Subject: [c-nsp] CALEA was Re:  OT - Dark Fiber
References: <48593.1251916052@lavin-llc.com><20090904152948.GA8726@saucer.midcoast.com>
	<alpine.BSF.2.00.0909041538060.69948@murf.icantclick.org>
	<02ae01ca2d9b$5fde85c0$2208120a@am.thmulti.com>
	<3DBA1CBE-560F-4D77-B04A-B945320A0422@puck.nether.net>
Message-ID: <02c601ca2d9e$676ba130$2208120a@am.thmulti.com>

What about Unlawful requests?  For example, suppose someone went to oh say 
ATT with out a Warrent and demanded they tap say most phones on their 
network?  Or let's say that someone from an alphabet soup organization taps 
you on the shoulder and demands access to your traffic for some sort of 
automated filtering?  Thankfully I don't work in an environment where this 
would ever come up but this was more of a thought experiment. I've worked in 
a few provider networks where law enforcement requests have come up but the 
requests always made sense along with the proper paper work accompanying 
them and honestly I've never first hand observed the type of wide scale 
monitoring that's been reported but the idea of the thing gives me the 
shivers. I'm sorry if this is off topic I'll drop the thread if it is but 
since CALEA was mentioned I was really curious why people bought in to it in 
the first place.


----- Original Message ----- 
From: "Jared Mauch" <jared at puck.nether.net>
To: "Scott Granados" <gsgranados at comcast.net>
Cc: "david raistrick" <drais at icantclick.org>; "jp" <jp at saucer.midcoast.com>; 
<cisco-nsp at puck.nether.net>
Sent: Friday, September 04, 2009 1:19 PM
Subject: Re: [c-nsp] CALEA was Re: OT - Dark Fiber


> Talk to your counsel about the compliance requests you get. You may be 
> able to get away without it, but you are required to comply with any 
> lawful requests, even if you don't like them. The same is true for any 
> business where you could get a lawful request for records.
>
> Check out packetforensics if you need a device, much cheaper than  others 
> in the space, their website can be a bit funny, but worth  having a [free] 
> login.
>
> - Jared
>
> On Sep 4, 2009, at 4:07 PM, Scott Granados wrote:
>
>> Why does anyone comply with CALEA?  Especially after the abuses of  the 
>> last 8 years and probably a lot farther back than that?  I've  been 
>> reading about the requirements and the idea that ISPs cooperate  with law 
>> enforcement really makes me uneasy on a civil liberties  basis. Does 
>> Uncle Sam scare tactic people in to compliance?  There's  just something 
>> about making things easier for the NSA and any number  of alphabet soup 
>> agencies that strikes me as unamerican (to use  their own phrase against 
>> them) and wrong. Or was it created simply  to create a new space for 
>> security products and C, J and the others  were really good at lobbying?
>>   Since it doesn't require the ISP to break open encrypted traffic  it 
>> almost makes me think a public key system that lets the end user  encrypt 
>> everything from phone to television with their own keys  makes some sense 
>> so there's nothing left in the clear for  entertaining the James Bond 
>> crowd! Probably not practical at all but  this thread just convinced me 
>> not to use split tunneling.;)
>>
>> ----- Original Message ----- From: "david raistrick" 
>> <drais at icantclick.org
>> >
>> To: "jp" <jp at saucer.midcoast.com>
>> Cc: <cisco-nsp at puck.nether.net>
>> Sent: Friday, September 04, 2009 12:40 PM
>> Subject: Re: [c-nsp] OT - Dark Fiber
>>
>>
>>> On Fri, 4 Sep 2009, jp wrote:
>>>
>>>> Regarding the topic... If someone provides dark fiber, would they be
>>>> subject to CALEA requirements to be able to tap and record the
>>>
>>> I haven't followed CALEA-for-ISPs for a few years, but at least  when it 
>>> was initially required, dark fiber providers won't need to  comply with 
>>> CALEA.  They're not providing network service.   -lit-  fiber providers 
>>> would because they're either providing network or  telecom 
>>> service....but they generally wouldn't do it at the  physical layer.
>>>
>>> ...david
>>>
>>> --
>>> david raistrick        http://www.netmeister.org/news/ learn2quote.html
>>> drais at icantclick.org             http://www.expita.com/nomime.html
>>>
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


From abalashov at evaristesys.com  Fri Sep  4 16:32:17 2009
From: abalashov at evaristesys.com (Alex Balashov)
Date: Fri, 4 Sep 2009 16:32:17 -0400
Subject: [c-nsp] CALEA was Re:  OT - Dark Fiber
In-Reply-To: <02ae01ca2d9b$5fde85c0$2208120a@am.thmulti.com>
References: <48593.1251916052@lavin-llc.com><20090904152948.GA8726@saucer.midcoast.com>
	<alpine.BSF.2.00.0909041538060.69948@murf.icantclick.org>
	<02ae01ca2d9b$5fde85c0$2208120a@am.thmulti.com>
Message-ID: <FCB163EB-EF74-48C9-9BEC-4903AB530E83@evaristesys.com>

Amen to that.

As I understand it it was mostly for the reason you cite - new and  
exciting captive market opportunities.



--
Sent from mobile device

On Sep 4, 2009, at 4:07 PM, "Scott Granados" <gsgranados at comcast.net>  
wrote:

> Why does anyone comply with CALEA?  Especially after the abuses of  
> the last 8 years and probably a lot farther back than that?  I've  
> been reading about the requirements and the idea that ISPs cooperate  
> with law enforcement really makes me uneasy on a civil liberties  
> basis. Does Uncle Sam scare tactic people in to compliance?  There's  
> just something about making things easier for the NSA and any number  
> of alphabet soup agencies that strikes me as unamerican (to use  
> their own phrase against them) and wrong. Or was it created simply  
> to create a new space for security products and C, J and the others  
> were really good at lobbying?
>   Since it doesn't require the ISP to break open encrypted traffic  
> it almost makes me think a public key system that lets the end user  
> encrypt everything from phone to television with their own keys  
> makes some sense so there's nothing left in the clear for  
> entertaining the James Bond crowd! Probably not practical at all but  
> this thread just convinced me not to use split tunneling.;)
>
> ----- Original Message ----- From: "david raistrick" <drais at icantclick.org 
> >
> To: "jp" <jp at saucer.midcoast.com>
> Cc: <cisco-nsp at puck.nether.net>
> Sent: Friday, September 04, 2009 12:40 PM
> Subject: Re: [c-nsp] OT - Dark Fiber
>
>
>> On Fri, 4 Sep 2009, jp wrote:
>>
>>> Regarding the topic... If someone provides dark fiber, would they be
>>> subject to CALEA requirements to be able to tap and record the
>>
>> I haven't followed CALEA-for-ISPs for a few years, but at least  
>> when it was initially required, dark fiber providers won't need to  
>> comply with CALEA.  They're not providing network service.   -lit-  
>> fiber providers would because they're either providing network or  
>> telecom service....but they generally wouldn't do it at the  
>> physical layer.
>>
>> ...david
>>
>> --
>> david raistrick        http://www.netmeister.org/news/ 
>> learn2quote.html
>> drais at icantclick.org             http://www.expita.com/nomime.html
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From tomas at soitron.com  Fri Sep  4 16:38:44 2009
From: tomas at soitron.com (Daniska, Tomas)
Date: Fri, 4 Sep 2009 22:38:44 +0200
Subject: [c-nsp] instabilities with SXI2?
In-Reply-To: <4AA11D64.1060800@cisco.com>
References: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>	<4A9CDB6A.6080607@imperial.ac.uk>	<20090901085317.GC2951@lboro.ac.uk>	<20090904081755.GO20558@skriver.dk>
	<4AA0DC20.9040703@Janoszka.pl>
	<6B43981C32F8464CB24CEE209DA32BD3025174CB@kenya.tronet.as>
	<4AA11D64.1060800@cisco.com>
Message-ID: <6B43981C32F8464CB24CEE209DA32BD302517536@kenya.tronet.as>

Rodney,

> -----Original Message-----
> From: Rodney Dunn [mailto:rodunn at cisco.com]
> 
> There are only 4 fixes in it.
> 
> CSCtb15569    VPN-SPA - traffic failed to decrypt due to SecInfo check
> failure
> 
> CSCtb27643    cat6000 Medium buffers leak on SP leading to crash
> 
> CSCsu65967    Modular IOS crash at free_lite_internal
> 
> And the 4th was just an ISSU matrix creation change.
> 
> Rodney
> 

I was secretly hoping that CSCta74242 be integrated in SXI2a. Do you
know if it's planned in SXI3 at least? I'm concerned about rolling out
SNMP health monitoring while this ddts is still in place.


Thanks for the fast update on 2a!

--

deejay

 

__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4394
(20090904) __________

Tuto spravu preveril ESET NOD32 Antivirus.

http://www.eset.sk
 

From jared at puck.nether.net  Fri Sep  4 16:43:40 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 4 Sep 2009 16:43:40 -0400
Subject: [c-nsp] CALEA was Re:  OT - Dark Fiber
In-Reply-To: <02c601ca2d9e$676ba130$2208120a@am.thmulti.com>
References: <48593.1251916052@lavin-llc.com><20090904152948.GA8726@saucer.midcoast.com>
	<alpine.BSF.2.00.0909041538060.69948@murf.icantclick.org>
	<02ae01ca2d9b$5fde85c0$2208120a@am.thmulti.com>
	<3DBA1CBE-560F-4D77-B04A-B945320A0422@puck.nether.net>
	<02c601ca2d9e$676ba130$2208120a@am.thmulti.com>
Message-ID: <FA3D9246-148B-481E-9AE5-15957A18E734@puck.nether.net>

On Sep 4, 2009, at 4:29 PM, Scott Granados wrote:

> What about Unlawful requests?

	You need not comply, and if you do, you could be breaking the law.

>  For example, suppose someone went to oh say ATT with out a Warrent  
> and demanded they tap say most phones on their network?

	NSL is the case where someone could ask for something, but wiretaps  
are something else. NSL is typically "who is the subscriber".

>  Or let's say that someone from an alphabet soup organization taps  
> you on the shoulder and demands access to your traffic for some sort  
> of automated filtering?

	I know a few of those types and they have never asked for or even  
talked around that sort of thing.

>  Thankfully I don't work in an environment where this would ever  
> come up but this was more of a thought experiment. I've worked in a  
> few provider networks where law enforcement requests have come up  
> but the requests always made sense along with the proper paper work  
> accompanying them and honestly I've never first hand observed the  
> type of wide scale monitoring that's been reported but the idea of  
> the thing gives me the shivers. I'm sorry if this is off topic I'll  
> drop the thread if it is but since CALEA was mentioned I was really  
> curious why people bought in to it in the first place.

	Calea was originally to cover the changeover of pstn to digital  
switches so they can track drug dealers, et al. While it also applies  
to "broadband" networks, Its not something you are likely to see. You  
can talk to the (i swear they are nice) CALEA Implementation unit  
about what you need. They are nice guys and there is no penalty for  
non-compliance unless you get a lawful request and are unable to  
comply. Then the FCC gets involved and you could be fined.

	Your best bet is to actually be social with your local FBI, Secret  
Service & Police. Tell them who you are, what you do, and when  
something comes up it wont seem like jackboot thugs :).

	Websites/things to google: askcalea.net, infragard.net

- Jared
>
>
> ----- Original Message ----- From: "Jared Mauch" <jared at puck.nether.net 
> >
> To: "Scott Granados" <gsgranados at comcast.net>
> Cc: "david raistrick" <drais at icantclick.org>; "jp" <jp at saucer.midcoast.com 
> >; <cisco-nsp at puck.nether.net>
> Sent: Friday, September 04, 2009 1:19 PM
> Subject: Re: [c-nsp] CALEA was Re: OT - Dark Fiber
>
>
>> Talk to your counsel about the compliance requests you get. You may  
>> be able to get away without it, but you are required to comply with  
>> any lawful requests, even if you don't like them. The same is true  
>> for any business where you could get a lawful request for records.
>>
>> Check out packetforensics if you need a device, much cheaper than   
>> others in the space, their website can be a bit funny, but worth   
>> having a [free] login.
>>
>> - Jared
>>
>> On Sep 4, 2009, at 4:07 PM, Scott Granados wrote:
>>
>>> Why does anyone comply with CALEA?  Especially after the abuses  
>>> of  the last 8 years and probably a lot farther back than that?   
>>> I've  been reading about the requirements and the idea that ISPs  
>>> cooperate  with law enforcement really makes me uneasy on a civil  
>>> liberties  basis. Does Uncle Sam scare tactic people in to  
>>> compliance?  There's  just something about making things easier  
>>> for the NSA and any number  of alphabet soup agencies that strikes  
>>> me as unamerican (to use  their own phrase against them) and  
>>> wrong. Or was it created simply  to create a new space for  
>>> security products and C, J and the others  were really good at  
>>> lobbying?
>>>  Since it doesn't require the ISP to break open encrypted traffic   
>>> it almost makes me think a public key system that lets the end  
>>> user  encrypt everything from phone to television with their own  
>>> keys  makes some sense so there's nothing left in the clear for   
>>> entertaining the James Bond crowd! Probably not practical at all  
>>> but  this thread just convinced me not to use split tunneling.;)
>>>
>>> ----- Original Message ----- From: "david raistrick" <drais at icantclick.org
>>> >
>>> To: "jp" <jp at saucer.midcoast.com>
>>> Cc: <cisco-nsp at puck.nether.net>
>>> Sent: Friday, September 04, 2009 12:40 PM
>>> Subject: Re: [c-nsp] OT - Dark Fiber
>>>
>>>
>>>> On Fri, 4 Sep 2009, jp wrote:
>>>>
>>>>> Regarding the topic... If someone provides dark fiber, would  
>>>>> they be
>>>>> subject to CALEA requirements to be able to tap and record the
>>>>
>>>> I haven't followed CALEA-for-ISPs for a few years, but at least   
>>>> when it was initially required, dark fiber providers won't need  
>>>> to  comply with CALEA.  They're not providing network service.   - 
>>>> lit-  fiber providers would because they're either providing  
>>>> network or  telecom service....but they generally wouldn't do it  
>>>> at the  physical layer.
>>>>
>>>> ...david
>>>>
>>>> --
>>>> david raistrick        http://www.netmeister.org/news/  
>>>> learn2quote.html
>>>> drais at icantclick.org             http://www.expita.com/nomime.html
>>>>
>>>> _______________________________________________
>>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/


From jp at saucer.midcoast.com  Fri Sep  4 16:51:17 2009
From: jp at saucer.midcoast.com (jp)
Date: Fri, 4 Sep 2009 16:51:17 -0400
Subject: [c-nsp] CALEA was Re:  OT - Dark Fiber
In-Reply-To: <02ae01ca2d9b$5fde85c0$2208120a@am.thmulti.com>
References: <alpine.BSF.2.00.0909041538060.69948@murf.icantclick.org>
	<02ae01ca2d9b$5fde85c0$2208120a@am.thmulti.com>
Message-ID: <20090904205117.GA11621@saucer.midcoast.com>

I've never had to capture traffic for the LEAs, but we do ocassionally 
get legit subpoenas to determine who was using what IP address at a 
particular time. We don't get to know much about the subpoenas, but I'd 
suspect it's a mix of child porn, drunk chatters making death threats 
online in public forums, etc...  I wouldn't be suprised if we someday 
had to capture traffic for an LEA, so I keep it in mind. I know for 
certain some of these are from customers with wide open wifi routers.

I think it's mostly a scam to make us do more paperwork and for vendors 
to sell more equipment or upgrades. The vendors were big on this. 
Encryption is the source of your civil liberty here.

The upside is that LEAs are probably supposed to be somewhat more
knowledgeable at asking for information in their subpoenas as a result 
of the existence of a process. Ten years ago, I was talking with a 
detective in charge of a subpoena I'd been served. I asked him what 
time zone, and he said Green Mountain Time. I am not joking.

On Fri, Sep 04, 2009 at 01:07:36PM -0700, Scott Granados wrote:
> Why does anyone comply with CALEA?  Especially after the abuses of the last 
> 8 years and probably a lot farther back than that?  I've been reading about 
> the requirements and the idea that ISPs cooperate with law enforcement 
> really makes me uneasy on a civil liberties basis. Does Uncle Sam scare 
> tactic people in to compliance?  There's just something about making things 
> easier for the NSA and any number of alphabet soup agencies that strikes me 
> as unamerican (to use their own phrase against them) and wrong. Or was it 
> created simply to create a new space for security products and C, J and the 
> others were really good at lobbying?
>    Since it doesn't require the ISP to break open encrypted traffic it 
> almost makes me think a public key system that lets the end user encrypt 
> everything from phone to television with their own keys makes some sense so 
> there's nothing left in the clear for entertaining the James Bond crowd! 
> Probably not practical at all but this thread just convinced me not to use 
> split tunneling.;)
>
> ----- Original Message ----- From: "david raistrick" <drais at icantclick.org>
> To: "jp" <jp at saucer.midcoast.com>
> Cc: <cisco-nsp at puck.nether.net>
> Sent: Friday, September 04, 2009 12:40 PM
> Subject: Re: [c-nsp] OT - Dark Fiber
>
>
>> On Fri, 4 Sep 2009, jp wrote:
>>
>>> Regarding the topic... If someone provides dark fiber, would they be
>>> subject to CALEA requirements to be able to tap and record the
>>
>> I haven't followed CALEA-for-ISPs for a few years, but at least when it 
>> was initially required, dark fiber providers won't need to comply with 
>> CALEA.  They're not providing network service.   -lit- fiber providers 
>> would because they're either providing network or telecom service....but 
>> they generally wouldn't do it at the physical layer.
>>
>> ...david
>>
>> --
>> david raistrick        http://www.netmeister.org/news/learn2quote.html
>> drais at icantclick.org             http://www.expita.com/nomime.html
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/ 

-- 
/*
Jason Philbrook   |   Midcoast Internet Solutions - Wireless and DSL
    KB1IOJ        |   Broadband Internet Access, Dialup, and Hosting 
 http://f64.nu/   |   for Midcoast Maine    http://www.midcoast.com/
*/

From gert at greenie.muc.de  Fri Sep  4 16:52:03 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 4 Sep 2009 22:52:03 +0200
Subject: [c-nsp] Options for customer prefix injection into iBGP at the
	edge
In-Reply-To: <4AA0197E.9010109@justinshore.com>
References: <4AA0197E.9010109@justinshore.com>
Message-ID: <20090904205203.GQ117@greenie.muc.de>

Hi,

On Thu, Sep 03, 2009 at 02:31:10PM -0500, Justin Shore wrote:
> A third option is redistributing statics into BGP.  This gives me the 
> opportunity to tag specific prefixes and filter them with a route-map so 
> I only redistribute the prefixes that I want redistributed.  I can also 
> name static routes.  I need a static route anyway to tack up the route 
> for outbound advertisement and to prevent loops.  

That's what we do.  Default is "export", and there's a tag for "no export"
(because that's something we only need very infrequently).

> The downside is that I 
> hate using redistribution.  I'm not a big fan of it.  I've been bit too 
> many times to consider redistribution a good method of doing anything. 

We haven't had any issues with "static -> <anything>" redistribution.

Effectively, having a "network" statement plus a static route is not
so different - just twice the configuration effort.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090904/01f6cb82/attachment.bin>

From mcgrath at fas.harvard.edu  Fri Sep  4 18:03:00 2009
From: mcgrath at fas.harvard.edu (Scott McGrath)
Date: Fri, 4 Sep 2009 18:03:00 -0400
Subject: [c-nsp] CALEA was Re:  OT - Dark Fiber
Message-ID: <13C9443BD0C7344D835569B0CFC9BB75358DBA52@HARVBE01.fasmail.priv>

Been there done that - bet detective was not amused when informed said timezone did not exist.    The alphabet soup guys often come calling at our shop.



-----Original Message-----

From:  "jp" <jp at saucer.midcoast.com>
Subj:  Re: [c-nsp] CALEA was Re:  OT - Dark Fiber
Date:  Fri Sep 4, 2009 16:55
Size:  2K
To:  "Scott Granados" <gsgranados at comcast.net>
cc:  "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>

I've never had to capture traffic for the LEAs, but we do ocassionally  
get legit subpoenas to determine who was using what IP address at a  
particular time. We don't get to know much about the subpoenas, but I'd  
suspect it's a mix of child porn, drunk chatters making death threats  
online in public forums, etc...  I wouldn't be suprised if we someday  
had to capture traffic for an LEA, so I keep it in mind. I know for  
certain some of these are from customers with wide open wifi routers. 
 
I think it's mostly a scam to make us do more paperwork and for vendors  
to sell more equipment or upgrades. The vendors were big on this.  
Encryption is the source of your civil liberty here. 
 
The upside is that LEAs are probably supposed to be somewhat more 
knowledgeable at asking for information in their subpoenas as a result  
of the existence of a process. Ten years ago, I was talking with a  
detective in charge of a subpoena I'd been served. I asked him what  
time zone, and he said Green Mountain Time. I am not joking. 
 
On Fri, Sep 04, 2009 at 01:07:36PM -0700, Scott Granados wrote: 
> Why does anyone comply with CALEA?  Especially after the abuses of the last  
> 8 years and probably a lot farther back than that?  I've been reading about  
> the requirements and the idea that ISPs cooperate with law enforcement  
> really makes me uneasy on a civil liberties basis. Does Uncle Sam scare  
> tactic people in to compliance?  There's just something about making things  
> easier for the NSA and any number of alphabet soup agencies that strikes me  
> as unamerican (to use their own phrase against them) and wrong. Or was it  
> created simply to create a new space for security products and C, J and the  
> others were really good at lobbying? 
>    Since it doesn't require the ISP to break open encrypted traffic it  
> almost makes me think a public key system that lets the end user encrypt  
> everything from phone to television with their own keys makes some sense so  
> there's nothing left in the clear f

From bitkraft at gmail.com  Fri Sep  4 19:26:42 2009
From: bitkraft at gmail.com (Brian Spade)
Date: Fri, 4 Sep 2009 16:26:42 -0700
Subject: [c-nsp] Syslog Solutions
Message-ID: <505b616c0909041626v5d40e10ds779863f1a3fbefee@mail.gmail.com>

Hi,

Can people recommend a useful solution for syslog, SNMP traps and event
correlation?  I'm not even sure where to start.  I know about syslog-ng but
am looking for a syslog/snmp trap collector with future capabilities of
event correlation.  The event correlation would be able to accept any data
source / device via SNMP or syslog.

Commercial or open-source is fine with the latter being more preferrable.

Thanks!
/bs

From brez at brezworks.com  Fri Sep  4 22:55:40 2009
From: brez at brezworks.com (Jeremy Bresley)
Date: Fri, 04 Sep 2009 21:55:40 -0500
Subject: [c-nsp] Syslog Solutions
In-Reply-To: <505b616c0909041626v5d40e10ds779863f1a3fbefee@mail.gmail.com>
References: <505b616c0909041626v5d40e10ds779863f1a3fbefee@mail.gmail.com>
Message-ID: <4AA1D32C.8020703@brezworks.com>

Two products to look at from the commercial realm would be Splunk ( 
http://www.splunk.com/ ) and Cisco CS-MARS ( 
http://www.cisco.com/en/US/products/ps6241/index.html )

Splunk doesn't directly take SNMP traps, but you can use snmptrapd to 
write the events to a file and have splunk index it.

MARS does take Syslog, SNMP traps, Netflow data, various IDS/IPS alerts 
and various other inputs ( 
http://www.cisco.com/en/US/docs/security/security_management/cs-mars/6.0/compatibility/local_controller/dtlc60x.html 
for the list of  supported devices.  Pretty much any Cisco product, 
Extreme routers, Juniper Netscreen/Checkpoint firewalls, etc)

MARS is sized based on either events/sec or Netflows per minute.  For a 
busy network, they can scale horizontally by using a Global Controller 
with multiple aggregators.

Good luck.

Jeremy

Brian Spade wrote:
> Hi,
>
> Can people recommend a useful solution for syslog, SNMP traps and event
> correlation?  I'm not even sure where to start.  I know about syslog-ng but
> am looking for a syslog/snmp trap collector with future capabilities of
> event correlation.  The event correlation would be able to accept any data
> source / device via SNMP or syslog.
>
> Commercial or open-source is fine with the latter being more preferrable.
>
> Thanks!
> /bs
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   


From gkg at gmx.de  Sat Sep  5 00:34:39 2009
From: gkg at gmx.de (Garry)
Date: Sat, 05 Sep 2009 06:34:39 +0200
Subject: [c-nsp] Syslog Solutions
In-Reply-To: <505b616c0909041626v5d40e10ds779863f1a3fbefee@mail.gmail.com>
References: <505b616c0909041626v5d40e10ds779863f1a3fbefee@mail.gmail.com>
Message-ID: <4AA1EA5F.7020903@gmx.de>

Brian Spade wrote:
> Hi,
> 
> Can people recommend a useful solution for syslog, SNMP traps and event
> correlation?  I'm not even sure where to start.  I know about syslog-ng but
> am looking for a syslog/snmp trap collector with future capabilities of
> event correlation.  The event correlation would be able to accept any data
> source / device via SNMP or syslog.

Not sure if it will cover your requirements, but OpenNMS does a pretty
good job with making both SNMP Traps and syslog messages readily
available, with lots of filtering possibilities and the likes ...

-garry

From mtinka at globaltransit.net  Sat Sep  5 00:39:31 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sat, 5 Sep 2009 12:39:31 +0800
Subject: [c-nsp] Options for customer prefix injection into iBGP at the
	edge
In-Reply-To: <4AA0197E.9010109@justinshore.com>
References: <4AA0197E.9010109@justinshore.com>
Message-ID: <200909051239.38746.mtinka@globaltransit.net>

On Friday 04 September 2009 03:31:10 am Justin Shore wrote:

> loops.  The downside is that I hate using redistribution.
>  I'm not a big fan of it.  I've been bit too many times
> to consider redistribution a good method of doing
> anything. It will also result in higher CPU load as the
> RIB is frequently parsed for statics and processed with
> the route-map if I'm not mistaken. Correct?

We find redistribution useful with l3vpn's, because the NLRI 
is only limited to the VRF in question.

Aside from that, no, we don't like to use it either 
(although one might argue that Route Leaking in IS-IS is a 
form of redistribution, between levels).

The other place where we've used redistribution is when we 
need to announce the management IP address of a switch that 
doesn't support IS-IS through via router it's connected to.

But moving on to your issue...

> What methods do my SP colleagues prefer to use when
> managing the injection of customer routes into iBGP?

So there's three kinds of scenarios we typically look at:

a) customers who are assigned address space from our
   allocation.

b) customers who have their own allocation but don't run BGP
   and have us announce it for them.

c) customers who have their own allocation and run BGP with
   us.


1. For customers that use our address space, each router is
   is assigned a /24 (more or less) from which customers'
   point-to-point addresses are derived. This is announced
   as a single route from that edge router.

   In addition, customers may be assigned additional address
   space for their LAN, e.t.c., which we announce to the
   network via:

	- static pull-up route
	- BGP network statement (Cisco)
	- route-filter entry (Juniper)

   We have a routing policy from each edge router to our
   route reflectors that sets the LOCAL_PREF and community
   values as necessary for all our aggregates + longer. This
   ensures any prefixes that belong to us which we assign to
   our customers maintain a consistent routing policy. This
   routing policy references a generic prefix list (Cisco)
   or route filter (Juniper).


2. For customers who have their own address space but don't
   run BGP with us, the point-to-point address policy as in
   1), above, applies.

   We also have a routing policy from each edge router to
   our route reflectors that sets the LOCAL_PREF and
   community values as necessary for these types of
   customers. This routing policy also references a generic
   prefix list (Cisco) or route filter (Juniper).


3. For customers who have their own allocation and run BGP
   with us, we have a standard outbound policy depending on
   whether customers want full, partial, customized or
   default routes. This policy also references a generic
   prefix list (Cisco) or route filter (Juniper).

   The inbound policy is either generic for non-kinky,
   standard eBGP turn-ups, or customized if customers
   require more specific policies. This policy also
   references a customized prefix list (Cisco) or route
   filter (Juniper). These lists are aptly named, making
   troubleshooting easier for the NOC.


In the case of 2), above, admittedly on an on-going 
operational basis, it is easier to inject customer prefixes 
into iBGP with Juniper because it's a 2-step process which 
also achieves filtering, rather than in Cisco where it's a 
3-step process with filtering.

In Juniper, all you do is:

a) write a pull-up static route.

b) write a route filter which is referenced by an iBGP
   export routing policy.


In Cisco, you achieve the same with one extra step:

a) write a pull-up static route.

b) write a prefix list which is reference by an iBGP
   route map.

c) write a 'network' statement in BGP.


However, the extra step with Cisco is not a big deal.

For the case of 3), above, the Cisco portion is just a two-
step process as in the Juniper case (with only a) and b) 
steps being required), as the customer routes are being 
generated by, well, the customer.

Hope this helps.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090905/a29ed59f/attachment.bin>

From gert at greenie.muc.de  Sat Sep  5 04:53:06 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Sat, 5 Sep 2009 10:53:06 +0200
Subject: [c-nsp] Options for customer prefix injection into iBGP at the
	edge
In-Reply-To: <200909051239.38746.mtinka@globaltransit.net>
References: <4AA0197E.9010109@justinshore.com>
	<200909051239.38746.mtinka@globaltransit.net>
Message-ID: <20090905085306.GR117@greenie.muc.de>

Hi,

On Sat, Sep 05, 2009 at 12:39:31PM +0800, Mark Tinka wrote:
> In Juniper, all you do is:
> 
> a) write a pull-up static route.
> 
> b) write a route filter which is referenced by an iBGP
>    export routing policy.
> 
> 
> In Cisco, you achieve the same with one extra step:
> 
> a) write a pull-up static route.
> 
> b) write a prefix list which is reference by an iBGP
>    route map.
> 
> c) write a 'network' statement in BGP.

"redistribute static route-map <something that references said prefix list>"

If you stop worrying about "redistribute is so evil", then things become
a lot less work :-)

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090905/fb3a3ebb/attachment.bin>

From mtinka at globaltransit.net  Sat Sep  5 05:54:12 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sat, 5 Sep 2009 17:54:12 +0800
Subject: [c-nsp] Options for customer prefix injection into iBGP at the
	edge
In-Reply-To: <20090905085306.GR117@greenie.muc.de>
References: <4AA0197E.9010109@justinshore.com>
	<200909051239.38746.mtinka@globaltransit.net>
	<20090905085306.GR117@greenie.muc.de>
Message-ID: <200909051754.17897.mtinka@globaltransit.net>

On Saturday 05 September 2009 04:53:06 pm Gert Doering 
wrote:

> "redistribute static route-map <something that references
> said prefix list>"
>
> If you stop worrying about "redistribute is so evil",
> then things become a lot less work :-)

Agree :-), considering that it takes just about the same 
amount of effort to setup the policy infrastructure on both 
platforms for this on-going O&M (assuming one prefers not to 
use the 'network' statements).

I guess the 'network' vs. 'redistribute' is a religious 
thing, even when it might not have to be :-).

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090905/a148845f/attachment-0001.bin>

From jckdaniels12 at gmail.com  Sat Sep  5 13:27:50 2009
From: jckdaniels12 at gmail.com (jack daniels)
Date: Sat, 5 Sep 2009 22:57:50 +0530
Subject: [c-nsp] boot variable issue
In-Reply-To: <8bb137f40909051027i702347ffu63628a334c7b6bae@mail.gmail.com>
References: <8bb137f40909051027i702347ffu63628a334c7b6bae@mail.gmail.com>
Message-ID: <8bb137f40909051027p2d1a43e4v1056dc71c94e8763@mail.gmail.com>

Hi All,

I have a querry for issue I'm facing---

If I put boot sequence -

sh bootvar
BOOT variable = cat4000-i5s-mz.122-25.EWA11.bin,1;
CONFIG_FILE variable does not exist
BOOTLDR variable does not exist
Configuration register is 0x2102




sh bootflash
-#- ED ----type---- --crc--- -seek-- nlen -length-
---------date/time--------- name
1   .. image        165C41B7  C74594   30 12535060 Jun 14 2007 01:25:48
+05:30 cat4000-i9s-mz.122-25.EWA8.bin
2   .. image        B9D0BD21 1848198   31 12401540 Nov 5 2007 11:13:00
+05:30 cat4000-i5s-mz.122-25.EWA11.bin
3   .D config       79E21BAD 1850F08    6    36078 Jun 26 2009 10:15:19
+05:30 backup
4   .. config       D3AEB40F 1859CD0    6    36165 Sep 5 2009 15:32:50
+05:30 backup


and the valid file is in BOOTFLASH , will switch look for file in bootflash
(BY DEFAULT - switch behaviour) when it doesnt finds file in FLASH.

Please send supporting doc if any.

Thanks and Regards
J.Daniels

From bh05gc at myblackberry.com  Sat Sep  5 15:54:22 2009
From: bh05gc at myblackberry.com (BH)
Date: Sat, 5 Sep 2009 15:54:22 -0400
Subject: [c-nsp] boot variable issue
In-Reply-To: <8bb137f40909051027p2d1a43e4v1056dc71c94e8763@mail.gmail.com>
References: <8bb137f40909051027i702347ffu63628a334c7b6bae@mail.gmail.com>
	<8bb137f40909051027p2d1a43e4v1056dc71c94e8763@mail.gmail.com>
Message-ID: <b067bc890909051254v461d9574h1d02d6a230459880@mail.gmail.com>

Not sure if I understood your question, but it seems the only thing you need
to do is:
conf t
  boot system flash bootflash:cat4000-i5s-mz.122-25.EWA11.bin
  end
wr

sh bootvar

You need to include the "bootflash:" part...


On Sat, Sep 5, 2009 at 13:27, jack daniels <jckdaniels12 at gmail.com> wrote:

> Hi All,
>
> I have a querry for issue I'm facing---
>
> If I put boot sequence -
>
> sh bootvar
> BOOT variable = cat4000-i5s-mz.122-25.EWA11.bin,1;
> CONFIG_FILE variable does not exist
> BOOTLDR variable does not exist
> Configuration register is 0x2102
>
>
>
>
> sh bootflash
> -#- ED ----type---- --crc--- -seek-- nlen -length-
> ---------date/time--------- name
> 1   .. image        165C41B7  C74594   30 12535060 Jun 14 2007 01:25:48
> +05:30 cat4000-i9s-mz.122-25.EWA8.bin
> 2   .. image        B9D0BD21 1848198   31 12401540 Nov 5 2007 11:13:00
> +05:30 cat4000-i5s-mz.122-25.EWA11.bin
> 3   .D config       79E21BAD 1850F08    6    36078 Jun 26 2009 10:15:19
> +05:30 backup
> 4   .. config       D3AEB40F 1859CD0    6    36165 Sep 5 2009 15:32:50
> +05:30 backup
>
>
> and the valid file is in BOOTFLASH , will switch look for file in bootflash
> (BY DEFAULT - switch behaviour) when it doesnt finds file in FLASH.
>
> Please send supporting doc if any.
>
> Thanks and Regards
> J.Daniels
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



-- 
BH

From andrea.montefusco at gmail.com  Sat Sep  5 16:28:16 2009
From: andrea.montefusco at gmail.com (Andrea Montefusco)
Date: Sat, 05 Sep 2009 22:28:16 +0200
Subject: [c-nsp] Syslog Solutions
In-Reply-To: <505b616c0909041626v5d40e10ds779863f1a3fbefee@mail.gmail.com>
References: <505b616c0909041626v5d40e10ds779863f1a3fbefee@mail.gmail.com>
Message-ID: <4AA2C9E0.5020205@gmail.com>

Brian Spade wrote:

> Can people recommend a useful solution for syslog, SNMP traps and event
> correlation?  I'm not even sure where to start.  I know about syslog-ng but
> am looking for a syslog/snmp trap collector with future capabilities of
> event correlation.  The event correlation would be able to accept any data
> source / device via SNMP or syslog.

If you know some regular expression and/or Perl, have a look to SEC
Simple Event Correlator. Simple but powerful IMHO.

For a revue of event correlation, see

http://www.cs.umb.edu/~rouilj/sec/sec_paper_full.pdf

it is a paper mainly system oriented but very useful for network too.

      *am*

---------------------------------------------------------
Andrea Montefusco iw0hdv        http://www.montefusco.com
tel: +393356992791                     fax: +390623318709
---------------------------------------------------------

From justin at justinshore.com  Sun Sep  6 11:00:52 2009
From: justin at justinshore.com (Justin Shore)
Date: Sun, 06 Sep 2009 10:00:52 -0500
Subject: [c-nsp] IDSM-2 Module VS. TippingPoint VS. Other IDS solutions
In-Reply-To: <F3318834F1F89D46857972DD4B411D70B0070F8F@EXCHANGE.thenap.com>
References: <F3318834F1F89D46857972DD4B411D70B0070F8F@EXCHANGE.thenap.com>
Message-ID: <4AA3CEA4.8090501@justinshore.com>

Drew Weaver wrote:
> Does anyone have any real world experience working with the IDSM-2 modules for the 6500 platform?
> 
> I am specifically trying to find people whom have used both the IDSM-2 vs. TippingPoint and even Vs other IDS products...
> 
> Any off-list or on-list anecdotes or opinions is highly appreciated.

I do have 1 tidbit to share.  First an explanation for those that don't 
know and the list archives.  IDSM2 modules have 2 operating modes. 
Inline and passive.  Inline is where you funnel traffic through them by 
mapping 2 VLANs to them for the inside and outside, sort of like the 
FWSM (BTW, like the FWSM the IDSM2 is not VRF-aware; using the VLANs is 
the solution for both LCs).  Passive is where you simply use an internal 
port span to get interesting traffic over to one of the IDSM2's internal 
ports.  IDMS2s ONLY operate in passive mode on 7600s or any other 
devices running SR.  Inline does not work.  If you happen running the 
older SR code that works on both 6500 and 7600s then you SOL.

We bought them IDMS2s and 7600s right in them middle of the BU split. 
Roughly 2.5 years later we're still waiting to get Cisco to take them 
back (trying to trade for a MARS appliance so it's still a sale for 
Cisco).  We've never used them, never been able to.  The product didn't 
work as advertised.  It was a Cisco Advanced Services SME that actually 
discovered the problem for us.  He found the problem acknowledged on an 
internal Cisco mailing list.  Nothing public has ever been said about it 
to the best of my knowledge.

Even if the IDMS2 actually worked in my 7600s I would still recommend a 
different solution.  It can only do 4 contexts.  That's not very much in 
the grand scheme of things.  That's not very much throughput for a 40G 
slot or even a 20G slot.  In fact I think it's like the FWSM2 and tops 
out at 6G.  Given the sheer expense of each context, that's not exactly 
something we can sell to our customers as an upsell service.  Personally 
I would recommend an appliance solution instead of a LC.  One of Cisco's 
appliance based solutions would be fine and cost less.  Cisco seems to 
be driving that way.  They EoLed the Anomaly Detector/Guard LCs for the 
7600s in favor of the appliance version.  I'm sure it's less expensive 
to produce, requires less interopt with other BUs and can be useful to 
other customers that don't have/need the larger chassis in that form factor.

My $.02
  Justin


From justin at justinshore.com  Sun Sep  6 11:13:38 2009
From: justin at justinshore.com (Justin Shore)
Date: Sun, 06 Sep 2009 10:13:38 -0500
Subject: [c-nsp] CALEA was Re:  OT - Dark Fiber
In-Reply-To: <02ae01ca2d9b$5fde85c0$2208120a@am.thmulti.com>
References: <48593.1251916052@lavin-llc.com><20090904152948.GA8726@saucer.midcoast.com>	<alpine.BSF.2.00.0909041538060.69948@murf.icantclick.org>
	<02ae01ca2d9b$5fde85c0$2208120a@am.thmulti.com>
Message-ID: <4AA3D1A2.9030100@justinshore.com>

Scott Granados wrote:
> Why does anyone comply with CALEA?  Especially after the abuses of the 
> last 8 years and probably a lot farther back than that?  I've been 
> reading about the requirements and the idea that ISPs cooperate with law 
> enforcement really makes me uneasy on a civil liberties basis. Does 
> Uncle Sam scare tactic people in to compliance?  There's just something 
> about making things easier for the NSA and any number of alphabet soup 
> agencies that strikes me as unamerican (to use their own phrase against 
> them) and wrong. Or was it created simply to create a new space for 
> security products and C, J and the others were really good at lobbying?
>    Since it doesn't require the ISP to break open encrypted traffic it 
> almost makes me think a public key system that lets the end user encrypt 
> everything from phone to television with their own keys makes some sense 
> so there's nothing left in the clear for entertaining the James Bond 
> crowd! Probably not practical at all but this thread just convinced me 
> not to use split tunneling.;)

Well, probably because it's REQUIRED BY LAW.  Not complying is a felony, 
not just a simple civil offense.  They go after company officers.  Try 
convincing your company officers not to do it; see if they want to take 
the chance.  All SPs were required to officially respond to the FTC with 
a plan for how they were going to make their network CALEA ready.  Not 
replying was not an option.

Politics of the last administration aside, it's not a bad thing that SPs 
be able to assist law enforcement.  Telcos have been required to do so 
for longer than most people on this list have been alive.  As voice 
traffic moves off the PSTN to the Internet logically CALEA has to 
follow.  Does that mean that the intelligence agencies will follow the 
letter of the law and not abuse it?  Certainly not.  The FBI has already 
shown that they will abuse it with National Security Letters.  That will 
happen under any administration though.  Hopefully it will be reduced 
under the present administration and the process will be tuned and 
refined.  Intelligence agencies (IAs) will always want more data and 
consumers and their SPs will always want to give up less.  The way we 
help limit the IAs is through the political processes, not through 
non-compliance.  An individual's civil disobedience seldom works.  Try 
non-compliance with the tax man and see how far you get.

Justin
  CALEA-compliant since 2007




From gkg at gmx.de  Mon Sep  7 01:47:54 2009
From: gkg at gmx.de (Garry)
Date: Mon, 07 Sep 2009 07:47:54 +0200
Subject: [c-nsp] VPN traffic to the Internet ... (ASA)
In-Reply-To: <4A9E5DE1.7060808@gmx.de>
References: <4A9E5DE1.7060808@gmx.de>
Message-ID: <4AA49E8A.4000801@gmx.de>

Garry wrote:
> After trying to get this to work for a while, I'm somewhat out of ideas ...
>
> I have a (otherwise working) VPN-connection from Windows clients (using
> Cisco VPN client) to an ASA, IP traffic from and to the internal network
> is working just fine. Now the problem comes up that the clients need to
> reach a site on the internet that is only accessable from certain IP
> ranges, which the mobile clients do not fall into.
>
> I thought, well, no problem, just extend the split tunneling to the
> destination IP. So far, so good, the client lists the destination in its
> list of tunneled IPs, and traffic to the destination is correctly sent
> through the tunnel. It is also correctly decoded on the ASA, but doesn't
> seem to go anywhere ...
>
> I've made sure that there's an internal rule allowing any access to that
> certain IP. I've also did a tcpdump on the destination to check if maybe
> the traffic isn't NATed correctly, but not a single packet is arriving
> through the ASA ...
>
> What am I missing here?
>   

Nobody?

From asturluismi at gmail.com  Mon Sep  7 04:16:48 2009
From: asturluismi at gmail.com (luismi)
Date: Mon, 07 Sep 2009 10:16:48 +0200
Subject: [c-nsp] Leaking specific routes from a VRF
In-Reply-To: <4A9E39D4.7090608@gmail.com>
References: <9445a3fb0909011149p1e744ecatf30cf3434d92aa2e@mail.gmail.com>
	<6B43981C32F8464CB24CEE209DA32BD302516F6C@kenya.tronet.as>
	<1251882322.11377.2.camel@dsba-ipso>  <4A9E39D4.7090608@gmail.com>
Message-ID: <1252311408.7378.3.camel@dsba-ipso>

Hi all,

We are doing some tests here with the code provided by Tomas.
We have several questions that we were not able to find a proper answer
over internet that we would like to share with you to see if we can
understand everything correctly:

a) "ip prefix-list" has a parameter called "le" so we can create the
rule like this: 

ip prefix-list FTP_NET seq 1 permit 10.53.0.224/29 le 32

Why is the reason to use "le" parameter? we saw it in several examples
over internet but we don't understand it yet.
What is the impact if we don't use it?

b) Is there any difference if we use a normal ACL instead a prefix-list
in the route-map? we also saw several configurations using ACLs and it
seems to do the same.

Regards and thanks in advance.


From eng_mssk at hotmail.com  Mon Sep  7 04:36:23 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Mon, 7 Sep 2009 11:36:23 +0300
Subject: [c-nsp] MIBs and OIDs
Message-ID: <BLU102-W1504B0EAECC087779DB264FAEB0@phx.gbl>


hey all 
what is the way to transform the MIBs to OIDs ?

_________________________________________________________________
Show them the way! Add maps and directions to your party invites. 
http://www.microsoft.com/windows/windowslive/products/events.aspx

From kajtzu at a51.org  Mon Sep  7 04:38:57 2009
From: kajtzu at a51.org (Kaj Niemi)
Date: Mon, 7 Sep 2009 01:38:57 -0700
Subject: [c-nsp] MIBs and OIDs
In-Reply-To: <BLU102-W1504B0EAECC087779DB264FAEB0@phx.gbl>
Message-ID: <C6CAA151.41E66%kajtzu@a51.org>


Take a look at snmptranslate from net-snmp. :)


Kaj



> From: Mohammad Khalil <eng_mssk at hotmail.com>
> Date: Mon, 7 Sep 2009 01:36:23 -0700
> To: <cisco-nsp at puck.nether.net>
> Subject: [c-nsp] MIBs and OIDs
> 
> 
> hey all
> what is the way to transform the MIBs to OIDs ?

From A.L.M.Buxey at lboro.ac.uk  Mon Sep  7 04:54:17 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Mon, 7 Sep 2009 09:54:17 +0100
Subject: [c-nsp] VPN traffic to the Internet ... (ASA)
In-Reply-To: <4AA49E8A.4000801@gmx.de>
References: <4A9E5DE1.7060808@gmx.de> <4AA49E8A.4000801@gmx.de>
Message-ID: <20090907085417.GA27465@lboro.ac.uk>

Hi,

> > What am I missing here?

your ASA cannot be that IP - so is probably just dropping
those packets as invalid... what you need to do is set up a
proxy (eq squid) on your internal network that has an address
within the 'allowed IP range' and then configure the ASA to
use that proxy - your mobile clients can then use that
proxy to get access to that address. ... .. but you may need
to check eg licencing to see if they're allowed to access
that resource when off your site (why is it protected to just
that IP address range in the first place? :-) )

alan

From vcappucc at cisco.com  Mon Sep  7 05:28:06 2009
From: vcappucc at cisco.com (Victor Cappuccio)
Date: Mon, 7 Sep 2009 12:28:06 +0300
Subject: [c-nsp] Leaking specific routes from a VRF
In-Reply-To: <1252311408.7378.3.camel@dsba-ipso>
References: <9445a3fb0909011149p1e744ecatf30cf3434d92aa2e@mail.gmail.com>
Message-ID: <001101ca2f9d$8289f290$879dd7b0$@com>

Hi Luisi, 

while I am not aware of the complete thread, I see that you are trying to
match VRF route information, using prefix-list or access-list:

For question A:

Basically the le parameter in the prefix list you show us, "ip prefix-list
FTP_NET seq 1 permit 10.53.0.224/29 le 32"
For me it means: to check the first 29 bits of the prefix 10.53.0.224 and
make sure that they match, 
Then it will check to make sure that the subnet mask is LESS THAN or EQUAL
to 32, the subnet mask can't be any lower than the bits we are checking. So
the valid range of subnet masks for this one would be 32 bits down to 29
bits (24,25,26,27-- and so on).
Please check out this article
https://cisco.hosted.jivesoftware.com/.../How%20do%20prefix%20list%20work.pd
f


And For question B:

A normal access-list CANNOT check the subnet mask of a network. It can only
check bits to make sure they match, nothing more. A prefix-list has an
advantage over an access-list in that it CAN check BOTH bits and subnet mask
- both would have to match for the network to be either permitted or denied.
Off course you can use extended access-list to filter route, and make them
behave just like a prefix-list, please take a look at the following link
http://tcpmag.com/qanda/article.asp?EditorialsID=358


Thanks

Victor Cappuccio.-
vcappucc at cisco.com
CCIE(R/S) #20657
STAC Support Engineer
Cisco Small Business Support.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of luismi
Sent: lunes, 07 de septiembre de 2009 11:17
To: Tomas Caslavsky
Cc: ivan.diaz at raxon.es; cisco-nsp at puck.nether.net; Daniska Tomas
Subject: Re: [c-nsp] Leaking specific routes from a VRF

Hi all,

We are doing some tests here with the code provided by Tomas.
We have several questions that we were not able to find a proper answer
over internet that we would like to share with you to see if we can
understand everything correctly:

a) "ip prefix-list" has a parameter called "le" so we can create the
rule like this: 

ip prefix-list FTP_NET seq 1 permit 10.53.0.224/29 le 32

Why is the reason to use "le" parameter? we saw it in several examples
over internet but we don't understand it yet.
What is the impact if we don't use it?

b) Is there any difference if we use a normal ACL instead a prefix-list
in the route-map? we also saw several configurations using ACLs and it
seems to do the same.

Regards and thanks in advance.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From b.turnbow at twt.it  Mon Sep  7 04:39:27 2009
From: b.turnbow at twt.it (Brian Turnbow)
Date: Mon, 7 Sep 2009 10:39:27 +0200
Subject: [c-nsp] Leaking specific routes from a VRF
In-Reply-To: <1252311408.7378.3.camel@dsba-ipso>
References: <9445a3fb0909011149p1e744ecatf30cf3434d92aa2e@mail.gmail.com><6B43981C32F8464CB24CEE209DA32BD302516F6C@kenya.tronet.as><1251882322.11377.2.camel@dsba-ipso>
	<4A9E39D4.7090608@gmail.com> <1252311408.7378.3.camel@dsba-ipso>
Message-ID: <F2207DB22012F94E92D7030F81A26294025A8721@twt-exch.milano.twt>


>-----Original Message-----
>From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of luismi
>Sent: luned? 7 settembre 2009 10.17
>To: Tomas Caslavsky
>Cc: ivan.diaz at raxon.es; cisco-nsp at puck.nether.net; Daniska Tomas
>Subject: Re: [c-nsp] Leaking specific routes from a VRF

>Hi all,

>We are doing some tests here with the code provided by Tomas.
>We have several questions that we were not able to find a proper answer
>over internet that we would like to share with you to see if we can
>understand everything correctly:

>a) "ip prefix-list" has a parameter called "le" so we can create the
>rule like this: 

>ip prefix-list FTP_NET seq 1 permit 10.53.0.224/29 le 32

>Why is the reason to use "le" parameter? we saw it in several examples
>over internet but we don't understand it yet.
>What is the impact if we don't use it?

Le works like "less than or equal to" 
So 10.53.0.224/29 le 32  matches any route less than or equal to a /32 inside your /29.
So if for example 10.53.0.228/32 arrives it matches, as will 10.53.0.224/30 or 10.53.0.224/29
Without le you match only the /29 so in the above example only the /29 matches.
This makes the use of prefix lists very flexible. 


>b) Is there any difference if we use a normal ACL instead a prefix-list
>in the route-map? we also saw several configurations using ACLs and it
>seems to do the same.

You can use them as well but lose the flexibility.

Brian

>Regards and thanks in advance.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From vcappucc at cisco.com  Mon Sep  7 05:47:52 2009
From: vcappucc at cisco.com (Victor Cappuccio)
Date: Mon, 7 Sep 2009 12:47:52 +0300
Subject: [c-nsp] Leaking specific routes from a VRF
In-Reply-To: <001101ca2f9d$8289f290$879dd7b0$@com>
References: <9445a3fb0909011149p1e744ecatf30cf3434d92aa2e@mail.gmail.com>
Message-ID: <001301ca2fa0$45888c50$d099a4f0$@com>

Typo in my email What is in parenthesis should be (32,31,30,29)

Sorry for the SPAM
 


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of vcappucc at cisco.com
Sent: lunes, 07 de septiembre de 2009 12:28
To: 'luismi'
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Leaking specific routes from a VRF

Hi Luisi, 

while I am not aware of the complete thread, I see that you are trying to
match VRF route information, using prefix-list or access-list:

For question A:

Basically the le parameter in the prefix list you show us, "ip prefix-list
FTP_NET seq 1 permit 10.53.0.224/29 le 32"
For me it means: to check the first 29 bits of the prefix 10.53.0.224 and
make sure that they match, 
Then it will check to make sure that the subnet mask is LESS THAN or EQUAL
to 32, the subnet mask can't be any lower than the bits we are checking. So
the valid range of subnet masks for this one would be 32 bits down to 29
bits (24,25,26,27-- and so on).
Please check out this article
https://cisco.hosted.jivesoftware.com/.../How%20do%20prefix%20list%20work.pd
f


And For question B:

A normal access-list CANNOT check the subnet mask of a network. It can only
check bits to make sure they match, nothing more. A prefix-list has an
advantage over an access-list in that it CAN check BOTH bits and subnet mask
- both would have to match for the network to be either permitted or denied.
Off course you can use extended access-list to filter route, and make them
behave just like a prefix-list, please take a look at the following link
http://tcpmag.com/qanda/article.asp?EditorialsID=358


Thanks

Victor Cappuccio.-
vcappucc at cisco.com
CCIE(R/S) #20657
STAC Support Engineer
Cisco Small Business Support.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of luismi
Sent: lunes, 07 de septiembre de 2009 11:17
To: Tomas Caslavsky
Cc: ivan.diaz at raxon.es; cisco-nsp at puck.nether.net; Daniska Tomas
Subject: Re: [c-nsp] Leaking specific routes from a VRF

Hi all,

We are doing some tests here with the code provided by Tomas.
We have several questions that we were not able to find a proper answer
over internet that we would like to share with you to see if we can
understand everything correctly:

a) "ip prefix-list" has a parameter called "le" so we can create the
rule like this: 

ip prefix-list FTP_NET seq 1 permit 10.53.0.224/29 le 32

Why is the reason to use "le" parameter? we saw it in several examples
over internet but we don't understand it yet.
What is the impact if we don't use it?

b) Is there any difference if we use a normal ACL instead a prefix-list
in the route-map? we also saw several configurations using ACLs and it
seems to do the same.

Regards and thanks in advance.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From ying-xiang at 163.com  Mon Sep  7 05:13:57 2009
From: ying-xiang at 163.com (ying-xiang)
Date: Mon, 7 Sep 2009 17:13:57 +0800 (CST)
Subject: [c-nsp] 6500 ipsec vpn
Message-ID: <13618054.353951252314837673.JavaMail.coremail@bj163app25.163.com>



hi
 
may i config ipsec vpn between two 6500 chassis without vpn service module?

From eng_mssk at hotmail.com  Mon Sep  7 07:32:54 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Mon, 7 Sep 2009 14:32:54 +0300
Subject: [c-nsp] Cisco ACS related
Message-ID: <BLU102-W175DDB3F072211A758AD9FAEB0@phx.gbl>


can i deny a certain command under configuration mode for certain authorization shell ?

_________________________________________________________________
With Windows Live, you can organize, edit, and share your photos.
http://www.microsoft.com/middleeast/windows/windowslive/products/photo-gallery-edit.aspx

From ler762 at gmail.com  Mon Sep  7 07:43:30 2009
From: ler762 at gmail.com (Lee)
Date: Mon, 7 Sep 2009 07:43:30 -0400
Subject: [c-nsp] MIBs and OIDs
In-Reply-To: <BLU102-W1504B0EAECC087779DB264FAEB0@phx.gbl>
References: <BLU102-W1504B0EAECC087779DB264FAEB0@phx.gbl>
Message-ID: <dd5f2deb0909070443je479527jb4f3d1de01a160f7@mail.gmail.com>

On 9/7/09, Mohammad Khalil <eng_mssk at hotmail.com> wrote:
>
> hey all
> what is the way to transform the MIBs to OIDs ?

as already mentioned, snmptranslate from http://net-snmp.sourceforge.net/

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en

get the file ftp://ftp.cisco.com/pub/mibs/oid/oid.tar.gz
unzip oid.tar.gz to OIDs
from a cygwin command prompt
  cd /cygdrive/c/ ..whatever.. /OIDs
  cat * | sort -k 2,2 -k 1 | uniq | nawk '{printf("%-50s  %s\n", $1,
$2) }' > ../oids_all.txt
  unix2dos ../oids_all.txt

Regards,
Lee

From gkg at gmx.de  Mon Sep  7 09:19:06 2009
From: gkg at gmx.de (Garry)
Date: Mon, 07 Sep 2009 15:19:06 +0200
Subject: [c-nsp] VPN traffic to the Internet ... (ASA)
In-Reply-To: <20090907085417.GA27465@lboro.ac.uk>
References: <4A9E5DE1.7060808@gmx.de> <4AA49E8A.4000801@gmx.de>
	<20090907085417.GA27465@lboro.ac.uk>
Message-ID: <4AA5084A.6000706@gmx.de>

Alan Buxey wrote:
> Hi,
> 
>>> What am I missing here?
> 
> your ASA cannot be that IP - so is probably just dropping
> those packets as invalid... what you need to do is set up a
> proxy (eq squid) on your internal network that has an address
> within the 'allowed IP range' and then configure the ASA to
> use that proxy - your mobile clients can then use that

So, say, I wouldn't have split tunneling - the ASA IOS isn't able to let
VPN clients get through to the Internet by doing a PAT or NAT on the way
out?


-gg

From spinthiras.mario at gmail.com  Mon Sep  7 09:52:15 2009
From: spinthiras.mario at gmail.com (Mario Spinthiras)
Date: Mon, 7 Sep 2009 14:52:15 +0100
Subject: [c-nsp] Syslog Solutions
In-Reply-To: <4AA2C9E0.5020205@gmail.com>
References: <505b616c0909041626v5d40e10ds779863f1a3fbefee@mail.gmail.com> 
	<4AA2C9E0.5020205@gmail.com>
Message-ID: <4f890e580909070652m5cc70c89s5d693f6993c873f9@mail.gmail.com>

Zenoss has syslog and snmp traps , its actually quite nice due to it's
integration with the rest of the monitoring system (hierarchies ,
notification settings) and it also takes repetitions in a time lapse in
order to avoid sending you hundreds of notifications and just sends a more
reasonable amount =) Do keep in mind however Zenoss is more a monitoring
solution overall and not just a snmp traps/syslog tool.


If you are looking for something more standalone, Splunk is also nice but
haven't had an in-depth with it.


Mario.

From thilak.t at gmail.com  Mon Sep  7 12:08:30 2009
From: thilak.t at gmail.com (Thilak T)
Date: Mon, 7 Sep 2009 09:08:30 -0700
Subject: [c-nsp] cisco-nsp Digest, Vol 82, Issue 34
In-Reply-To: <mailman.3.1252339201.40923.cisco-nsp@puck.nether.net>
References: <mailman.3.1252339201.40923.cisco-nsp@puck.nether.net>
Message-ID: <1d11fbf80909070908s6a2cfcf6g5973d59d2983c4d0@mail.gmail.com>

IPSeC VPN termination 6500 chassis with SPA module is not supported.
You can bring up IPSec Tunnel , however it wont work as expected , I
have seen sup720 cpu hitting 80 to 90 % even for 1Mbps traffic.IPSec
connection w/o SPA is not reliable and supported.

Thanks

Thilak Thankappan


On Mon, Sep 7, 2009 at 9:00 AM, <cisco-nsp-request at puck.nether.net> wrote:
> Send cisco-nsp mailing list submissions to
> ? ? ? ?cisco-nsp at puck.nether.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> ? ? ? ?https://puck.nether.net/mailman/listinfo/cisco-nsp
> or, via email, send a message with subject or body 'help' to
> ? ? ? ?cisco-nsp-request at puck.nether.net
>
> You can reach the person managing the list at
> ? ? ? ?cisco-nsp-owner at puck.nether.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cisco-nsp digest..."
>
>
> Today's Topics:
>
> ? 1. 6500 ipsec vpn (ying-xiang)
> ? 2. Cisco ACS related (Mohammad Khalil)
> ? 3. Re: MIBs and OIDs (Lee)
> ? 4. Re: VPN traffic to the Internet ... (ASA) (Garry)
> ? 5. Re: Syslog Solutions (Mario Spinthiras)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 7 Sep 2009 17:13:57 +0800 (CST)
> From: ying-xiang <ying-xiang at 163.com>
> To: cisco-nsp <cisco-nsp at puck.nether.net>
> Subject: [c-nsp] 6500 ipsec vpn
> Message-ID:
> ? ? ? ?<13618054.353951252314837673.JavaMail.coremail at bj163app25.163.com>
> Content-Type: text/plain; charset=gbk
>
>
>
> hi
>
> may i config ipsec vpn between two 6500 chassis without vpn service module?
>
> ------------------------------
>
> Message: 2
> Date: Mon, 7 Sep 2009 14:32:54 +0300
> From: Mohammad Khalil <eng_mssk at hotmail.com>
> To: <cisco-nsp at puck.nether.net>
> Subject: [c-nsp] Cisco ACS related
> Message-ID: <BLU102-W175DDB3F072211A758AD9FAEB0 at phx.gbl>
> Content-Type: text/plain; charset="windows-1256"
>
>
> can i deny a certain command under configuration mode for certain authorization shell ?
>
> _________________________________________________________________
> With Windows Live, you can organize, edit, and share your photos.
> http://www.microsoft.com/middleeast/windows/windowslive/products/photo-gallery-edit.aspx
>
> ------------------------------
>
> Message: 3
> Date: Mon, 7 Sep 2009 07:43:30 -0400
> From: Lee <ler762 at gmail.com>
> To: Mohammad Khalil <eng_mssk at hotmail.com>
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] MIBs and OIDs
> Message-ID:
> ? ? ? ?<dd5f2deb0909070443je479527jb4f3d1de01a160f7 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 9/7/09, Mohammad Khalil <eng_mssk at hotmail.com> wrote:
>>
>> hey all
>> what is the way to transform the MIBs to OIDs ?
>
> as already mentioned, snmptranslate from http://net-snmp.sourceforge.net/
>
> http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en
>
> get the file ftp://ftp.cisco.com/pub/mibs/oid/oid.tar.gz
> unzip oid.tar.gz to OIDs
> from a cygwin command prompt
> ?cd /cygdrive/c/ ..whatever.. /OIDs
> ?cat * | sort -k 2,2 -k 1 | uniq | nawk '{printf("%-50s ?%s\n", $1,
> $2) }' > ../oids_all.txt
> ?unix2dos ../oids_all.txt
>
> Regards,
> Lee
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 07 Sep 2009 15:19:06 +0200
> From: Garry <gkg at gmx.de>
> To: Alan Buxey <A.L.M.Buxey at lboro.ac.uk>
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] VPN traffic to the Internet ... (ASA)
> Message-ID: <4AA5084A.6000706 at gmx.de>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Alan Buxey wrote:
>> Hi,
>>
>>>> What am I missing here?
>>
>> your ASA cannot be that IP - so is probably just dropping
>> those packets as invalid... what you need to do is set up a
>> proxy (eq squid) on your internal network that has an address
>> within the 'allowed IP range' and then configure the ASA to
>> use that proxy - your mobile clients can then use that
>
> So, say, I wouldn't have split tunneling - the ASA IOS isn't able to let
> VPN clients get through to the Internet by doing a PAT or NAT on the way
> out?
>
>
> -gg
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 7 Sep 2009 14:52:15 +0100
> From: Mario Spinthiras <spinthiras.mario at gmail.com>
> To: Cisco Network Service Providers <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] Syslog Solutions
> Message-ID:
> ? ? ? ?<4f890e580909070652m5cc70c89s5d693f6993c873f9 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Zenoss has syslog and snmp traps , its actually quite nice due to it's
> integration with the rest of the monitoring system (hierarchies ,
> notification settings) and it also takes repetitions in a time lapse in
> order to avoid sending you hundreds of notifications and just sends a more
> reasonable amount =) Do keep in mind however Zenoss is more a monitoring
> solution overall and not just a snmp traps/syslog tool.
>
>
> If you are looking for something more standalone, Splunk is also nice but
> haven't had an in-depth with it.
>
>
> Mario.
>
>
> ------------------------------
>
> _______________________________________________
> cisco-nsp mailing list
> cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
>
> End of cisco-nsp Digest, Vol 82, Issue 34
> *****************************************
>

From rwest at zyedge.com  Mon Sep  7 12:53:16 2009
From: rwest at zyedge.com (Ryan West)
Date: Mon, 7 Sep 2009 12:53:16 -0400
Subject: [c-nsp] VPN traffic to the Internet ... (ASA)
In-Reply-To: <4AA5084A.6000706@gmx.de>
References: <4A9E5DE1.7060808@gmx.de> <4AA49E8A.4000801@gmx.de>
	<20090907085417.GA27465@lboro.ac.uk> <4AA5084A.6000706@gmx.de>
Message-ID: <655B25DD-8CC8-4B76-91B7-F3C72B3738FC@zyedge.com>

It can. You need allow same interface traffic and configure nat outside.

Sent from handheld.

On Sep 7, 2009, at 9:31 AM, "Garry" <gkg at gmx.de> wrote:

> Alan Buxey wrote:
>> Hi,
>>
>>>> What am I missing here?
>>
>> your ASA cannot be that IP - so is probably just dropping
>> those packets as invalid... what you need to do is set up a
>> proxy (eq squid) on your internal network that has an address
>> within the 'allowed IP range' and then configure the ASA to
>> use that proxy - your mobile clients can then use that
>
> So, say, I wouldn't have split tunneling - the ASA IOS isn't able to  
> let
> VPN clients get through to the Internet by doing a PAT or NAT on the  
> way
> out?
>
>
> -gg
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From rwest at zyedge.com  Mon Sep  7 13:43:01 2009
From: rwest at zyedge.com (Ryan West)
Date: Mon, 7 Sep 2009 13:43:01 -0400
Subject: [c-nsp] VPN traffic to the Internet ...
In-Reply-To: <D0E08F7D-D5F1-4276-B2CA-3EEE8BCDC828@zyedge.com>
References: <4A9E5DE1.7060808@gmx.de>
	<D0E08F7D-D5F1-4276-B2CA-3EEE8BCDC828@zyedge.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248E26A092@zy-ex1.zyedge.local>

Garry,

I sent this to you on the 2nd, did you ever try it?

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00805734ae.shtml


-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ryan West
Sent: Wednesday, September 02, 2009 8:09 AM
To: Garry
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] VPN traffic to the Internet ...

  nat (outside) 1 VPN range and
Same-security intrainterface.

Sent from handheld.

On Sep 2, 2009, at 8:05 AM, "Garry" <gkg at gmx.de> wrote:

> After trying to get this to work for a while, I'm somewhat out of  
> ideas ...
>
> I have a (otherwise working) VPN-connection from Windows clients  
> (using
> Cisco VPN client) to an ASA, IP traffic from and to the internal  
> network
> is working just fine. Now the problem comes up that the clients need  
> to
> reach a site on the internet that is only accessable from certain IP
> ranges, which the mobile clients do not fall into.
>
> I thought, well, no problem, just extend the split tunneling to the
> destination IP. So far, so good, the client lists the destination in  
> its
> list of tunneled IPs, and traffic to the destination is correctly sent
> through the tunnel. It is also correctly decoded on the ASA, but  
> doesn't
> seem to go anywhere ...
>
> I've made sure that there's an internal rule allowing any access to  
> that
> certain IP. I've also did a tcpdump on the destination to check if  
> maybe
> the traffic isn't NATed correctly, but not a single packet is arriving
> through the ASA ...
>
> What am I missing here?
>
> Tnx, -garry
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From arla at rn.dk  Mon Sep  7 14:34:29 2009
From: arla at rn.dk (Arne Larsen / Region Nordjylland)
Date: Mon, 7 Sep 2009 20:34:29 +0200
Subject: [c-nsp] primary and backup routing with ISIS
Message-ID: <8D68760F464FFD40A01BF2FB374E4A2801CC1C850C55@SRVEXC02.aas.its.nja.dk>

Hi all.

Can someone give me at hint how to configure routing in an MPLS network that carries VPN's.
We are using ISIS as IGP and MBGP to announce VPN routes.
The problem is, our PE-routers have one 10Gb and one 1Gb uplink on 5 sites. We would like to be sure that the traffic is routed via the 10G interface as primary and only use the 1G as backup. How is that done, and what is the best choice ??

/Arne

From sthaug at nethelp.no  Mon Sep  7 14:54:32 2009
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Mon, 07 Sep 2009 20:54:32 +0200 (CEST)
Subject: [c-nsp] primary and backup routing with ISIS
In-Reply-To: <8D68760F464FFD40A01BF2FB374E4A2801CC1C850C55@SRVEXC02.aas.its.nja.dk>
References: <8D68760F464FFD40A01BF2FB374E4A2801CC1C850C55@SRVEXC02.aas.its.nja.dk>
Message-ID: <20090907.205432.41709152.sthaug@nethelp.no>

> Can someone give me at hint how to configure routing in an MPLS network that carries VPN's.
> We are using ISIS as IGP and MBGP to announce VPN routes.
> The problem is, our PE-routers have one 10Gb and one 1Gb uplink on 5 sites. We would like to be sure that the traffic is routed via the 10G interface as primary and only use the 1G as backup. How is that done, and what is the best choice ??

The normal way of doing this would be to use IGP metrics - set the 1Gb
link to have a metric 10 times the 10 Gb link. Unfortunately Cisco has
not yet implemented "auto-cost reference-bandwidth" for IS-IS, so you
have to set the link metrics manually.

Oh yeah, you *really really* want to use IS-IS wide metrics.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From gkg at gmx.de  Tue Sep  8 01:43:02 2009
From: gkg at gmx.de (Garry)
Date: Tue, 08 Sep 2009 07:43:02 +0200
Subject: [c-nsp] VPN traffic to the Internet ...
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248E26A092@zy-ex1.zyedge.local>
References: <4A9E5DE1.7060808@gmx.de>
	<D0E08F7D-D5F1-4276-B2CA-3EEE8BCDC828@zyedge.com>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248E26A092@zy-ex1.zyedge.local>
Message-ID: <4AA5EEE6.3080102@gmx.de>

Ryan, Scott,

Ryan West wrote:
> Garry,
> 
> I sent this to you on the 2nd, did you ever try it?
> 
> http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00805734ae.shtml

This function did fix it ... I didn't see that option as relevant for
the VPN connection, but I can understand how it's meant now ...

Thanks, -garry

From chris.garzon at gmail.com  Tue Sep  8 03:50:48 2009
From: chris.garzon at gmail.com (Dracul)
Date: Tue, 8 Sep 2009 15:50:48 +0800
Subject: [c-nsp] cisco 4503 port security
Message-ID: <876789290909080050w96f8240p946d9a51dd1d5dec@mail.gmail.com>

Hi List,

has anybody experienced doing port isolation / port-security using the cisco
4503?
I can't seem to find the best way to do it since the IOS doesn't have
port-security option in the CLI.

regards,
Chris

From avayner at cisco.com  Tue Sep  8 04:02:47 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Tue, 8 Sep 2009 10:02:47 +0200
Subject: [c-nsp] cisco 4503 port security
In-Reply-To: <876789290909080050w96f8240p946d9a51dd1d5dec@mail.gmail.com>
References: <876789290909080050w96f8240p946d9a51dd1d5dec@mail.gmail.com>
Message-ID: <FDD1CDB3FB499E4087CC7670BBCA22C6372F5A@XMB-AMS-101.cisco.com>

Chris,

This is the latest config guide:
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/conf
iguration/guide/port_sec.html

Could be some older IOS or low end SUP?

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Dracul
Sent: Tuesday, September 08, 2009 10:51
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] cisco 4503 port security

Hi List,

has anybody experienced doing port isolation / port-security using the
cisco
4503?
I can't seem to find the best way to do it since the IOS doesn't have
port-security option in the CLI.

regards,
Chris
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From chris.garzon at gmail.com  Tue Sep  8 04:19:46 2009
From: chris.garzon at gmail.com (Dracul)
Date: Tue, 8 Sep 2009 16:19:46 +0800
Subject: [c-nsp] cisco 4503 port security
In-Reply-To: <FDD1CDB3FB499E4087CC7670BBCA22C6372F5A@XMB-AMS-101.cisco.com>
References: <876789290909080050w96f8240p946d9a51dd1d5dec@mail.gmail.com>
	<FDD1CDB3FB499E4087CC7670BBCA22C6372F5A@XMB-AMS-101.cisco.com>
Message-ID: <876789290909080119q777b977oec1272f96c1041a2@mail.gmail.com>

Thanks Arie,

I was trying to do a port that is trunked then apply port-security. I think
this doesn't give the option. The only next thing to do
perhaps is to try it with access-list or pvlan? But the the thing with pvlan
is, will it complicate the config using other vlans
on top of that?

regards,
chris


On Tue, Sep 8, 2009 at 4:02 PM, Arie Vayner (avayner) <avayner at cisco.com>wrote:

> Chris,
>
> This is the latest config guide:
> http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/conf
> iguration/guide/port_sec.html<http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/conf%0Aiguration/guide/port_sec.html>
>
> Could be some older IOS or low end SUP?
>
> Arie
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Dracul
> Sent: Tuesday, September 08, 2009 10:51
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] cisco 4503 port security
>
> Hi List,
>
> has anybody experienced doing port isolation / port-security using the
> cisco
> 4503?
> I can't seem to find the best way to do it since the IOS doesn't have
> port-security option in the CLI.
>
> regards,
> Chris
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From p.mayers at imperial.ac.uk  Tue Sep  8 06:30:39 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Tue, 08 Sep 2009 11:30:39 +0100
Subject: [c-nsp] Change VRF RD
Message-ID: <4AA6324F.4060504@imperial.ac.uk>

All,

When we deployed our MPLS core, we made the minor mistake of setting the 
RD the same on every router.

On the platform we're using (6500/sup720, 12.2(33)SXI) you don't seem to 
be able to change the rd of a defined VRF; you have to "no rd" which 
promptly blows away the "router bgp / address family ipv4 vrf X" as well 
as the route-target statements; and it won't let you enter a new rd for 
~60 seconds, claiming:

% Deletion of "rd" in progress; wait for it to complete

This is obviously hugely unhelpful for correcting the mistake.

Does anyone know if this is possible either without an outage or with a 
very short one? Or are we stuck with taking the outage?

From dave.kruger at mtnbusiness.co.za  Tue Sep  8 08:04:13 2009
From: dave.kruger at mtnbusiness.co.za (Dave Kruger)
Date: Tue, 08 Sep 2009 14:04:13 +0200
Subject: [c-nsp] ISIS Adj-filter problem
In-Reply-To: <a48927f70908191440x7c1d0a36u995e6a759758731b@mail.gmail.com>
References: <a48927f70908191440x7c1d0a36u995e6a759758731b@mail.gmail.com>
Message-ID: <4AA6483D.9080102@mtnbusiness.co.za>

Hi there

have u managed to figure out what was causing that?

Did you see that your clns filter references

49.0001.0000.0000.0100.00


where as your R1 router's Sys ID is

49.0001.0000.0000.0001.00


Regards,
Dave

Ibrahim Abo Zaid wrote:
> Hi All
>
> I was testing ISIS Adj-filter option , R1,R2 and R3 are connected over
> ethernet switch (using dynamips) with the below configuration
>
> the configuration works for adj point and both R2 and R3 have ADJ with R1
> only , the problem is R2 is droping R1 and R3 LSPs and debug shows it is
> dropped due to invalid adj . can you help to resolve that ?
>
> Configuration
>
> R1
> interface Loopback0
>  ip address 10.10.1.1 255.255.255.255
> !
> interface FastEthernet0/0
>  ip address 10.10.123.1 255.255.255.0
>  ip router isis
>
> router isis
>  net 
>   

>  is-type level-1
>  passive-interface Loopback0
>
> R2
> interface Loopback0
>  ip address 10.10.2.2 255.255.255.255
> !
> interface FastEthernet0/0
>  ip address 10.10.123.2 255.255.255.0
>  ip router isis
>  isis adjacency-filter A1
> !
>   router isis
>  net 49.0001.0000.0000.0002.00
>  is-type level-1
>  passive-interface Loopback0
>
> clns filter-set A1 permit 49.0001.0000.0000.0100.00
>
> R3
>
> interface Loopback0
>  ip address 10.10.3.3 255.255.255.255
> !
> interface FastEthernet0/0
>  ip address 10.10.123.3 255.255.255.0
>  ip router isis
>  isis adjacency-filter A1
>
>
> router isis
>  net 49.0001.0000.0000.0003.00
>  is-type level-1
>  passive-interface Loopback0
>
>  clns filter-set A1 permit 49.0001.0000.0000.0100.00
>
>
> verification
>
>
> R1#sh clns neighbors
> System Id      Interface   SNPA                State  Holdtime  Type
> Protocol
> R2             Fa0/0       c201.0544.0000      Up     8         L1   IS-IS
> R3             Fa0/0       c202.0544.0000      Up     7         L1   IS-IS
>
> R1 has R2 and R3 LSPs
>
> R1#sh isis database
> IS-IS Level-1 Link State Database:
> LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
> R1.00-00            * 0x00000010   0x2D88        849               0/0/0
> R2.00-00              0x00000009   0x8037        1036              0/0/0
> R2.01-00              0x00000003   0x78D8        1036              0/0/0
> R3.00-00              0x00000005   0x4470        552               0/0/0
> R3.01-00              0x00000006   0x78D3        1091              0/0/0
>
> but has R3-Lo0 route ONLY !!
>
> R1#sh ip route isis
>      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
> i L1    10.10.3.3/32 [115/10] via 10.10.123.3, FastEthernet0/0
>
> R2#sh clns neighbors
> System Id      Interface   SNPA                State  Holdtime  Type
> Protocol
> R1             Fa0/0       c200.0544.0000      Up     21        L1   IS-IS
>
> R2 don't have R1 and R3 LSPs !!!
>
>
> R2#sh isis database
> IS-IS Level-1 Link State Database:
> LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
> R2.00-00            * 0x00000009   0x8037        985               0/0/0
> R2.01-00            * 0x00000003   0x78D8        986               0/0/0
>
> NO ISIS Route  , it normal no LSP :)
> R2#sh ip route isis
> R2#
>
> R3
>
> R3#sh clns neighbors
> System Id      Interface   SNPA                State  Holdtime  Type
> Protocol
> R1             Fa0/0       c200.0544.0000      Up     26        L1   IS-IS
>
> R3#sh isis database
> IS-IS Level-1 Link State Database:
> LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
> R1.00-00              0x00000013   0x278B        1181              0/0/0
> R2.00-00              0x00000009   0x8037        845               0/0/0
> R2.01-00              0x00000003   0x78D8        846               0/0/0
> R3.00-00            * 0x00000006   0x4271        1186              0/0/0
> R3.01-00            * 0x00000007   0x76D4        1185              0/0/0
>
> route to R1-Lo0 only !!
>
> R3#sh ip route isis
>      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
> i L1    10.10.1.1/32 [115/10] via 10.10.123.1, FastEthernet0/0
>
> debug isis update-packets shows update is dropped due to invalid ADJ
>
>
> *Mar  1 00:30:16.751: ISIS-Upd: Invalid adjacency
> *Mar  1 00:30:26.619: ISIS-Upd: Invalid adjacency
> *Mar  1 00:30:34.151: ISIS-Upd: Invalid adjacency
>
> any ideas
>
> best regards
> --Ibrahim
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   


From James.Munroe at gnb.ca  Tue Sep  8 08:02:51 2009
From: James.Munroe at gnb.ca (Munroe, James   (DSS/MAS))
Date: Tue, 8 Sep 2009 09:02:51 -0300
Subject: [c-nsp] Syslog Solutions
In-Reply-To: <4f890e580909070652m5cc70c89s5d693f6993c873f9@mail.gmail.com>
References: <505b616c0909041626v5d40e10ds779863f1a3fbefee@mail.gmail.com>
	<4AA2C9E0.5020205@gmail.com>
	<4f890e580909070652m5cc70c89s5d693f6993c873f9@mail.gmail.com>
Message-ID: <A8FAD6BE9C01384A9C3CC962F184D34563C983DA53@GNBEX1.gnb.ca>

Could look at Q1 Labs as well.  They now offer a Free VM version:  http://www.q1labs.com/qradar-slim-fe/

-----Original Message-----
From: Mario Spinthiras [mailto:spinthiras.mario at gmail.com] 
Sent: Monday, September 07, 2009 10:52 AM
To: Cisco Network Service Providers
Subject: Re: [c-nsp] Syslog Solutions

Zenoss has syslog and snmp traps , its actually quite nice due to it's
integration with the rest of the monitoring system (hierarchies ,
notification settings) and it also takes repetitions in a time lapse in
order to avoid sending you hundreds of notifications and just sends a more
reasonable amount =) Do keep in mind however Zenoss is more a monitoring
solution overall and not just a snmp traps/syslog tool.


If you are looking for something more standalone, Splunk is also nice but
haven't had an in-depth with it.


Mario.


From vcappucc at cisco.com  Tue Sep  8 08:56:49 2009
From: vcappucc at cisco.com (Victor Cappuccio)
Date: Tue, 8 Sep 2009 15:56:49 +0300
Subject: [c-nsp] ISIS Adj-filter problem
In-Reply-To: <4AA6483D.9080102@mtnbusiness.co.za>
References: <a48927f70908191440x7c1d0a36u995e6a759758731b@mail.gmail.com>
Message-ID: <003301ca3083$d595e520$80c1af60$@com>

Hi,

Did you tried the same command but not on the DIS??  On a LAN, one of the
routers elects itself the DIS, based on interface priority (the default is
64). If all interface priorities are the same, the router with the highest
subnetwork point of attachment (SNPA) is selected

I did your same configuration, but now I applied the filter to all the
router but the DIS. 

R2 in this case is the DIS!

R2#show run int f0/0
Building configuration...

Current configuration : 132 bytes
!
interface FastEthernet0/0
 ip address 10.10.123.2 255.255.255.0
 ip router isis
 duplex auto
 speed auto
 isis priority 127
end

R2#show clns neigh

System Id      Interface   SNPA                State  Holdtime  Type
Protocol
R3             Fa0/0       c003.163c.0000      Up     25        L1   IS-IS
R1             Fa0/0       c001.163c.0000      Up     29        L1   IS-IS
R2#show clns is-

System Id      Interface   State  Type Priority  Circuit Id         Format
R3             Fa0/0       Up     L1   64        R2.01              Phase V
R1             Fa0/0       Up     L1   64        R2.01              Phase V
R2#

R2#show ip route isis
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
i L1    10.10.3.3/32 [115/10] via 10.10.123.3, FastEthernet0/0
i L1    10.10.1.1/32 [115/10] via 10.10.123.1, FastEthernet0/0


---

R1#show run int f0/0
Building configuration...

Current configuration : 140 bytes
!
interface FastEthernet0/0
 ip address 10.10.123.1 255.255.255.0
 ip router isis
 duplex auto
 speed auto
 isis adjacency-filter R2
end

R1#show run | in clns filter
clns filter-set R2 permit 49.0001.0000.0000.0002.00
R1#show isis neigh

System Id      Type Interface IP Address      State Holdtime Circuit Id
R2             L1   Fa0/0     10.10.123.2     UP    9        R2.01
R1#show ip route isis
     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
i L1    10.10.2.2/32 [115/10] via 10.10.123.2, FastEthernet0/0
R1#

----


R3#show run int f0/0
Building configuration...

Current configuration : 140 bytes
!
interface FastEthernet0/0
 ip address 10.10.123.3 255.255.255.0
 ip router isis
 duplex auto
 speed auto
 isis adjacency-filter R2
end

R3#show run | in clns filter
clns filter-set R2 permit 49.0001.0000.0000.0002.00
R3#show clns neigh

System Id      Interface   SNPA                State  Holdtime  Type
Protocol
R2             Fa0/0       c002.163c.0000      Up     7         L1   IS-IS
R3#
R3#show clns is-neighbors

System Id      Interface   State  Type Priority  Circuit Id         Format
R2             Fa0/0       Up     L1   127       R2.01              Phase V
R3#show ip route isis
     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
i L1    10.10.2.2/32 [115/10] via 10.10.123.2, FastEthernet0/0
R3#


Thanks,

Victor Cappuccio.-
vcappucc at cisco.com
CCIE(R/S) #20657
STAC Support Engineer
Cisco Small Business Support.

 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Dave Kruger
Sent: martes, 08 de septiembre de 2009 15:04
To: Ibrahim Abo Zaid
Cc: cisco_nsp
Subject: Re: [c-nsp] ISIS Adj-filter problem

Hi there

have u managed to figure out what was causing that?

Did you see that your clns filter references

49.0001.0000.0000.0100.00


where as your R1 router's Sys ID is

49.0001.0000.0000.0001.00


Regards,
Dave

Ibrahim Abo Zaid wrote:
> Hi All
>
> I was testing ISIS Adj-filter option , R1,R2 and R3 are connected over
> ethernet switch (using dynamips) with the below configuration
>
> the configuration works for adj point and both R2 and R3 have ADJ with R1
> only , the problem is R2 is droping R1 and R3 LSPs and debug shows it is
> dropped due to invalid adj . can you help to resolve that ?
>
> Configuration
>
> R1
> interface Loopback0
>  ip address 10.10.1.1 255.255.255.255
> !
> interface FastEthernet0/0
>  ip address 10.10.123.1 255.255.255.0
>  ip router isis
>
> router isis
>  net 
>   

>  is-type level-1
>  passive-interface Loopback0
>
> R2
> interface Loopback0
>  ip address 10.10.2.2 255.255.255.255
> !
> interface FastEthernet0/0
>  ip address 10.10.123.2 255.255.255.0
>  ip router isis
>  isis adjacency-filter A1
> !
>   router isis
>  net 49.0001.0000.0000.0002.00
>  is-type level-1
>  passive-interface Loopback0
>
> clns filter-set A1 permit 49.0001.0000.0000.0100.00
>
> R3
>
> interface Loopback0
>  ip address 10.10.3.3 255.255.255.255
> !
> interface FastEthernet0/0
>  ip address 10.10.123.3 255.255.255.0
>  ip router isis
>  isis adjacency-filter A1
>
>
> router isis
>  net 49.0001.0000.0000.0003.00
>  is-type level-1
>  passive-interface Loopback0
>
>  clns filter-set A1 permit 49.0001.0000.0000.0100.00
>
>
> verification
>
>
> R1#sh clns neighbors
> System Id      Interface   SNPA                State  Holdtime  Type
> Protocol
> R2             Fa0/0       c201.0544.0000      Up     8         L1   IS-IS
> R3             Fa0/0       c202.0544.0000      Up     7         L1   IS-IS
>
> R1 has R2 and R3 LSPs
>
> R1#sh isis database
> IS-IS Level-1 Link State Database:
> LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime
ATT/P/OL
> R1.00-00            * 0x00000010   0x2D88        849               0/0/0
> R2.00-00              0x00000009   0x8037        1036              0/0/0
> R2.01-00              0x00000003   0x78D8        1036              0/0/0
> R3.00-00              0x00000005   0x4470        552               0/0/0
> R3.01-00              0x00000006   0x78D3        1091              0/0/0
>
> but has R3-Lo0 route ONLY !!
>
> R1#sh ip route isis
>      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
> i L1    10.10.3.3/32 [115/10] via 10.10.123.3, FastEthernet0/0
>
> R2#sh clns neighbors
> System Id      Interface   SNPA                State  Holdtime  Type
> Protocol
> R1             Fa0/0       c200.0544.0000      Up     21        L1   IS-IS
>
> R2 don't have R1 and R3 LSPs !!!
>
>
> R2#sh isis database
> IS-IS Level-1 Link State Database:
> LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime
ATT/P/OL
> R2.00-00            * 0x00000009   0x8037        985               0/0/0
> R2.01-00            * 0x00000003   0x78D8        986               0/0/0
>
> NO ISIS Route  , it normal no LSP :)
> R2#sh ip route isis
> R2#
>
> R3
>
> R3#sh clns neighbors
> System Id      Interface   SNPA                State  Holdtime  Type
> Protocol
> R1             Fa0/0       c200.0544.0000      Up     26        L1   IS-IS
>
> R3#sh isis database
> IS-IS Level-1 Link State Database:
> LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime
ATT/P/OL
> R1.00-00              0x00000013   0x278B        1181              0/0/0
> R2.00-00              0x00000009   0x8037        845               0/0/0
> R2.01-00              0x00000003   0x78D8        846               0/0/0
> R3.00-00            * 0x00000006   0x4271        1186              0/0/0
> R3.01-00            * 0x00000007   0x76D4        1185              0/0/0
>
> route to R1-Lo0 only !!
>
> R3#sh ip route isis
>      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
> i L1    10.10.1.1/32 [115/10] via 10.10.123.1, FastEthernet0/0
>
> debug isis update-packets shows update is dropped due to invalid ADJ
>
>
> *Mar  1 00:30:16.751: ISIS-Upd: Invalid adjacency
> *Mar  1 00:30:26.619: ISIS-Upd: Invalid adjacency
> *Mar  1 00:30:34.151: ISIS-Upd: Invalid adjacency
>
> any ideas
>
> best regards
> --Ibrahim
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From peter at rathlev.dk  Tue Sep  8 10:21:03 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Tue, 08 Sep 2009 16:21:03 +0200
Subject: [c-nsp] Change VRF RD
In-Reply-To: <4AA6324F.4060504@imperial.ac.uk>
References: <4AA6324F.4060504@imperial.ac.uk>
Message-ID: <1252419663.6643.2.camel@abehat.net.rm.dk>

On Tue, 2009-09-08 at 11:30 +0100, Phil Mayers wrote:
> When we deployed our MPLS core, we made the minor mistake of setting the 
> RD the same on every router.
> 
> On the platform we're using (6500/sup720, 12.2(33)SXI) you don't seem to 
> be able to change the rd of a defined VRF; you have to "no rd" which 
> promptly blows away the "router bgp / address family ipv4 vrf X" as well 
> as the route-target statements; and it won't let you enter a new rd for 
> ~60 seconds, claiming:
> 
> % Deletion of "rd" in progress; wait for it to complete
> 
> This is obviously hugely unhelpful for correcting the mistake.
> 
> Does anyone know if this is possible either without an outage or with a 
> very short one? Or are we stuck with taking the outage?

AFAIK there's no way around it. And AFAIK it's not Sup720 specific.

With redundant nodes you can of course remove one node from the equation
at a time and then change it, but with only one node there's no luck.

You could avoid the "deletion in progress" by giving the VRF both a new
name and a new RD; this doesn't remove the BGP convergence time though.

-- 
Peter



From rsm at fast-serv.com  Tue Sep  8 06:40:12 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 8 Sep 2009 06:40:12 -0400
Subject: [c-nsp] service-policy on virtual interface
In-Reply-To: <1252419663.6643.2.camel@abehat.net.rm.dk>
References: <4AA6324F.4060504@imperial.ac.uk>
	<1252419663.6643.2.camel@abehat.net.rm.dk>
Message-ID: <20090908103823.M72119@fast-serv.com>

Do the same commands work e.g. 'service-policy input/output FooPolicy' at the
virtual interface level the same as they do on a physical port, both in and out?  

I'm trying to set up rate limiting 'further up the line' rather than at the
network edge, so we can pool customer bandwidth and keep inbound floods of
traffic from being passed beyond the distribution layer.

--
Randy

From Ian.Mackinnon at lumison.net  Tue Sep  8 10:44:57 2009
From: Ian.Mackinnon at lumison.net (Ian MacKinnon)
Date: Tue, 8 Sep 2009 15:44:57 +0100
Subject: [c-nsp] service-policy on virtual interface
In-Reply-To: <20090908103823.M72119@fast-serv.com>
References: <4AA6324F.4060504@imperial.ac.uk>
	<1252419663.6643.2.camel@abehat.net.rm.dk>
	<20090908103823.M72119@fast-serv.com>
Message-ID: <B5F945E48C137C49A98BC86DD35939C0156B8685A7@nbg01-exch-01.entlstaff.domain.lumison.net>

Hi Randy,
What platform?
On 6500/7600 the answer is yes, you need mls qos vlan-based on the physical interfaces and then you can police on the SVI.

Ian

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Randy McAnally
Sent: 08 September 2009 11:40
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] service-policy on virtual interface

Do the same commands work e.g. 'service-policy input/output FooPolicy' at the
virtual interface level the same as they do on a physical port, both in and out?

I'm trying to set up rate limiting 'further up the line' rather than at the
network edge, so we can pool customer bandwidth and keep inbound floods of
traffic from being passed beyond the distribution layer.

--
Randy
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.81/2350 - Release Date: 09/07/09 18:03:00

--

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender. Any
offers or quotation of service are subject to formal specification.
Errors and omissions excepted.  Please note that any views or opinions
presented in this email are solely those of the author and do not
necessarily represent those of Lumison.
Finally, the recipient should check this email and any attachments for the
presence of viruses.  Lumison accept no liability for any
damage caused by any virus transmitted by this email.

From rsm at fast-serv.com  Tue Sep  8 06:53:56 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 8 Sep 2009 06:53:56 -0400
Subject: [c-nsp] service-policy on virtual interface
In-Reply-To: <B5F945E48C137C49A98BC86DD35939C0156B8685A7@nbg01-exch-01.entlstaff.domain.lumison.net>
References: <4AA6324F.4060504@imperial.ac.uk>
	<1252419663.6643.2.camel@abehat.net.rm.dk>
	<20090908103823.M72119@fast-serv.com>
	<B5F945E48C137C49A98BC86DD35939C0156B8685A7@nbg01-exch-01.entlstaff.domain.lumison.net>
Message-ID: <20090908105205.M98445@fast-serv.com>

6500 platform.

Last time we had 'mls qos' enabled we had massive speed/packet loss issues
with interfaces over 40% utilization since we don't classify traffic.

Is there any possible issues you might see?

--
Randy

---------- Original Message -----------
From: Ian MacKinnon <Ian.Mackinnon at lumison.net>
To: Randy McAnally <rsm at fast-serv.com>, "cisco-nsp at puck.nether.net"
<cisco-nsp at puck.nether.net>
Sent: Tue, 8 Sep 2009 15:44:57 +0100
Subject: RE: [c-nsp] service-policy on virtual interface

> Hi Randy,
> What platform?
> On 6500/7600 the answer is yes, you need mls qos vlan-based on the 
> physical interfaces and then you can police on the SVI.
> 
> Ian
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Randy McAnally Sent: 08 
> September 2009 11:40 To: cisco-nsp at puck.nether.net Subject: [c-nsp] 
> service-policy on virtual interface
> 
> Do the same commands work e.g. 'service-policy input/output 
> FooPolicy' at the virtual interface level the same as they do on a 
> physical port, both in and out?
> 
> I'm trying to set up rate limiting 'further up the line' rather than 
> at the network edge, so we can pool customer bandwidth and keep 
> inbound floods of traffic from being passed beyond the distribution layer.
> 
> --
> Randy
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> 
> Version: 8.5.409 / Virus Database: 270.13.81/2350 - Release Date: 
> 09/07/09 18:03:00
> 
> --
> 
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender. 
> Any offers or quotation of service are subject to formal specification.
> Errors and omissions excepted.  Please note that any views or 
> opinions presented in this email are solely those of the author and 
> do not necessarily represent those of Lumison. Finally, the 
> recipient should check this email and any attachments for the 
> presence of viruses.  Lumison accept no liability for any damage 
> caused by any virus transmitted by this email.
------- End of Original Message -------


From Ian.Mackinnon at lumison.net  Tue Sep  8 11:05:57 2009
From: Ian.Mackinnon at lumison.net (Ian MacKinnon)
Date: Tue, 8 Sep 2009 16:05:57 +0100
Subject: [c-nsp] service-policy on virtual interface
In-Reply-To: <20090908105205.M98445@fast-serv.com>
References: <4AA6324F.4060504@imperial.ac.uk>
	<1252419663.6643.2.camel@abehat.net.rm.dk>
	<20090908103823.M72119@fast-serv.com>
	<B5F945E48C137C49A98BC86DD35939C0156B8685A7@nbg01-exch-01.entlstaff.domain.lumison.net>
	<20090908105205.M98445@fast-serv.com>
Message-ID: <B5F945E48C137C49A98BC86DD35939C0156B8685B9@nbg01-exch-01.entlstaff.domain.lumison.net>

Not seen problems turning on mls qos.
We have on the physicals :-
Int gi1/1
mls qos vlan-based
mls qos trust dscp
and a typical service policy looks like :-
policy-map 10MegPolice
  class class-default
   police 10000000 26000 32000    conform-action transmit     exceed-action transmit     violate-action drop

what do you mean you don't classify?

Ian


-----Original Message-----
From: Randy McAnally [mailto:rsm at fast-serv.com]
Sent: 08 September 2009 11:54
To: Ian MacKinnon; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] service-policy on virtual interface

6500 platform.

Last time we had 'mls qos' enabled we had massive speed/packet loss issues
with interfaces over 40% utilization since we don't classify traffic.

Is there any possible issues you might see?

--
Randy

---------- Original Message -----------
From: Ian MacKinnon <Ian.Mackinnon at lumison.net>
To: Randy McAnally <rsm at fast-serv.com>, "cisco-nsp at puck.nether.net"
<cisco-nsp at puck.nether.net>
Sent: Tue, 8 Sep 2009 15:44:57 +0100
Subject: RE: [c-nsp] service-policy on virtual interface

> Hi Randy,
> What platform?
> On 6500/7600 the answer is yes, you need mls qos vlan-based on the
> physical interfaces and then you can police on the SVI.
>
> Ian
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Randy McAnally Sent: 08
> September 2009 11:40 To: cisco-nsp at puck.nether.net Subject: [c-nsp]
> service-policy on virtual interface
>
> Do the same commands work e.g. 'service-policy input/output
> FooPolicy' at the virtual interface level the same as they do on a
> physical port, both in and out?
>
> I'm trying to set up rate limiting 'further up the line' rather than
> at the network edge, so we can pool customer bandwidth and keep
> inbound floods of traffic from being passed beyond the distribution layer.
>
> --
> Randy
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
>
> Version: 8.5.409 / Virus Database: 270.13.81/2350 - Release Date:
> 09/07/09 18:03:00
>
> --
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender.
> Any offers or quotation of service are subject to formal specification.
> Errors and omissions excepted.  Please note that any views or
> opinions presented in this email are solely those of the author and
> do not necessarily represent those of Lumison. Finally, the
> recipient should check this email and any attachments for the
> presence of viruses.  Lumison accept no liability for any damage
> caused by any virus transmitted by this email.
------- End of Original Message -------


No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.81/2350 - Release Date: 09/07/09 18:03:00

--

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender. Any
offers or quotation of service are subject to formal specification.
Errors and omissions excepted.  Please note that any views or opinions
presented in this email are solely those of the author and do not
necessarily represent those of Lumison.
Finally, the recipient should check this email and any attachments for the
presence of viruses.  Lumison accept no liability for any
damage caused by any virus transmitted by this email.

From rsm at fast-serv.com  Tue Sep  8 07:13:24 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 8 Sep 2009 07:13:24 -0400
Subject: [c-nsp] service-policy on virtual interface
In-Reply-To: <B5F945E48C137C49A98BC86DD35939C0156B8685B9@nbg01-exch-01.entlstaff.domain.lumison.net>
References: <4AA6324F.4060504@imperial.ac.uk>
	<1252419663.6643.2.camel@abehat.net.rm.dk>
	<20090908103823.M72119@fast-serv.com>
	<B5F945E48C137C49A98BC86DD35939C0156B8685A7@nbg01-exch-01.entlstaff.domain.lumison.net>
	<20090908105205.M98445@fast-serv.com>
	<B5F945E48C137C49A98BC86DD35939C0156B8685B9@nbg01-exch-01.entlstaff.domain.lumison.net>
Message-ID: <20090908111116.M10856@fast-serv.com>

By 'not classify' I meant all of our traffic is in the same default class. 
Could you verify that 'mls qos' is not needed globally before you can do 'mls
qos vlan-based' on an interface?

Cheers

--
Randy

---------- Original Message -----------
From: Ian MacKinnon <Ian.Mackinnon at lumison.net>
To: Randy McAnally <rsm at fast-serv.com>, "cisco-nsp at puck.nether.net"
<cisco-nsp at puck.nether.net>
Sent: Tue, 8 Sep 2009 16:05:57 +0100
Subject: RE: [c-nsp] service-policy on virtual interface

> Not seen problems turning on mls qos.
> We have on the physicals :-
> Int gi1/1
> mls qos vlan-based
> mls qos trust dscp
> and a typical service policy looks like :-
> policy-map 10MegPolice
>   class class-default
>    police 10000000 26000 32000    conform-action transmit     exceed-
> action transmit     violate-action drop
> 
> what do you mean you don't classify?
> 
> Ian
> 
> -----Original Message-----
> From: Randy McAnally [mailto:rsm at fast-serv.com]
> Sent: 08 September 2009 11:54
> To: Ian MacKinnon; cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] service-policy on virtual interface
> 
> 6500 platform.
> 
> Last time we had 'mls qos' enabled we had massive speed/packet loss issues
> with interfaces over 40% utilization since we don't classify traffic.
> 
> Is there any possible issues you might see?
> 
> --
> Randy
> 
> ---------- Original Message -----------
> From: Ian MacKinnon <Ian.Mackinnon at lumison.net>
> To: Randy McAnally <rsm at fast-serv.com>, "cisco-nsp at puck.nether.net"
> <cisco-nsp at puck.nether.net>
> Sent: Tue, 8 Sep 2009 15:44:57 +0100
> Subject: RE: [c-nsp] service-policy on virtual interface
> 
> > Hi Randy,
> > What platform?
> > On 6500/7600 the answer is yes, you need mls qos vlan-based on the
> > physical interfaces and then you can police on the SVI.
> >
> > Ian
> >
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> > bounces at puck.nether.net] On Behalf Of Randy McAnally Sent: 08
> > September 2009 11:40 To: cisco-nsp at puck.nether.net Subject: [c-nsp]
> > service-policy on virtual interface
> >
> > Do the same commands work e.g. 'service-policy input/output
> > FooPolicy' at the virtual interface level the same as they do on a
> > physical port, both in and out?
> >
> > I'm trying to set up rate limiting 'further up the line' rather than
> > at the network edge, so we can pool customer bandwidth and keep
> > inbound floods of traffic from being passed beyond the distribution layer.
> >
> > --
> > Randy
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> >
> > Version: 8.5.409 / Virus Database: 270.13.81/2350 - Release Date:
> > 09/07/09 18:03:00
> >
> > --
> >
> > This email and any files transmitted with it are confidential and intended
> > solely for the use of the individual or entity to whom they are addressed.
> > If you have received this email in error please notify the sender.
> > Any offers or quotation of service are subject to formal specification.
> > Errors and omissions excepted.  Please note that any views or
> > opinions presented in this email are solely those of the author and
> > do not necessarily represent those of Lumison. Finally, the
> > recipient should check this email and any attachments for the
> > presence of viruses.  Lumison accept no liability for any damage
> > caused by any virus transmitted by this email.
> ------- End of Original Message -------
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> 
> Version: 8.5.409 / Virus Database: 270.13.81/2350 - Release Date: 
> 09/07/09 18:03:00
> 
> --
> 
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender. 
> Any offers or quotation of service are subject to formal specification.
> Errors and omissions excepted.  Please note that any views or 
> opinions presented in this email are solely those of the author and 
> do not necessarily represent those of Lumison. Finally, the 
> recipient should check this email and any attachments for the 
> presence of viruses.  Lumison accept no liability for any damage 
> caused by any virus transmitted by this email.
------- End of Original Message -------


From Ian.Mackinnon at lumison.net  Tue Sep  8 11:16:35 2009
From: Ian.Mackinnon at lumison.net (Ian MacKinnon)
Date: Tue, 8 Sep 2009 16:16:35 +0100
Subject: [c-nsp] service-policy on virtual interface
In-Reply-To: <20090908111116.M10856@fast-serv.com>
References: <4AA6324F.4060504@imperial.ac.uk>
	<1252419663.6643.2.camel@abehat.net.rm.dk>
	<20090908103823.M72119@fast-serv.com>
	<B5F945E48C137C49A98BC86DD35939C0156B8685A7@nbg01-exch-01.entlstaff.domain.lumison.net>
	<20090908105205.M98445@fast-serv.com>
	<B5F945E48C137C49A98BC86DD35939C0156B8685B9@nbg01-exch-01.entlstaff.domain.lumison.net>
	<20090908111116.M10856@fast-serv.com>
Message-ID: <B5F945E48C137C49A98BC86DD35939C0156B8685CA@nbg01-exch-01.entlstaff.domain.lumison.net>

I <think> it is required, not 100% sure.

Our policers are just using the default class, but I think by default it will then use different queues on the actual hardware.

In my understanding the policing and queuing is completely separate.

Ian

-----Original Message-----
From: Randy McAnally [mailto:rsm at fast-serv.com]
Sent: 08 September 2009 12:13
To: Ian MacKinnon; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] service-policy on virtual interface

By 'not classify' I meant all of our traffic is in the same default class.
Could you verify that 'mls qos' is not needed globally before you can do 'mls
qos vlan-based' on an interface?

Cheers

--
Randy

---------- Original Message -----------
From: Ian MacKinnon <Ian.Mackinnon at lumison.net>
To: Randy McAnally <rsm at fast-serv.com>, "cisco-nsp at puck.nether.net"
<cisco-nsp at puck.nether.net>
Sent: Tue, 8 Sep 2009 16:05:57 +0100
Subject: RE: [c-nsp] service-policy on virtual interface

> Not seen problems turning on mls qos.
> We have on the physicals :-
> Int gi1/1
> mls qos vlan-based
> mls qos trust dscp
> and a typical service policy looks like :-
> policy-map 10MegPolice
>   class class-default
>    police 10000000 26000 32000    conform-action transmit     exceed-
> action transmit     violate-action drop
>
> what do you mean you don't classify?
>
> Ian
>
> -----Original Message-----
> From: Randy McAnally [mailto:rsm at fast-serv.com]
> Sent: 08 September 2009 11:54
> To: Ian MacKinnon; cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] service-policy on virtual interface
>
> 6500 platform.
>
> Last time we had 'mls qos' enabled we had massive speed/packet loss issues
> with interfaces over 40% utilization since we don't classify traffic.
>
> Is there any possible issues you might see?
>
> --
> Randy
>
> ---------- Original Message -----------
> From: Ian MacKinnon <Ian.Mackinnon at lumison.net>
> To: Randy McAnally <rsm at fast-serv.com>, "cisco-nsp at puck.nether.net"
> <cisco-nsp at puck.nether.net>
> Sent: Tue, 8 Sep 2009 15:44:57 +0100
> Subject: RE: [c-nsp] service-policy on virtual interface
>
> > Hi Randy,
> > What platform?
> > On 6500/7600 the answer is yes, you need mls qos vlan-based on the
> > physical interfaces and then you can police on the SVI.
> >
> > Ian
> >
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> > bounces at puck.nether.net] On Behalf Of Randy McAnally Sent: 08
> > September 2009 11:40 To: cisco-nsp at puck.nether.net Subject: [c-nsp]
> > service-policy on virtual interface
> >
> > Do the same commands work e.g. 'service-policy input/output
> > FooPolicy' at the virtual interface level the same as they do on a
> > physical port, both in and out?
> >
> > I'm trying to set up rate limiting 'further up the line' rather than
> > at the network edge, so we can pool customer bandwidth and keep
> > inbound floods of traffic from being passed beyond the distribution layer.
> >
> > --
> > Randy
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> >
> > Version: 8.5.409 / Virus Database: 270.13.81/2350 - Release Date:
> > 09/07/09 18:03:00
> >
> > --
> >
> > This email and any files transmitted with it are confidential and intended
> > solely for the use of the individual or entity to whom they are addressed.
> > If you have received this email in error please notify the sender.
> > Any offers or quotation of service are subject to formal specification.
> > Errors and omissions excepted.  Please note that any views or
> > opinions presented in this email are solely those of the author and
> > do not necessarily represent those of Lumison. Finally, the
> > recipient should check this email and any attachments for the
> > presence of viruses.  Lumison accept no liability for any damage
> > caused by any virus transmitted by this email.
> ------- End of Original Message -------
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
>
> Version: 8.5.409 / Virus Database: 270.13.81/2350 - Release Date:
> 09/07/09 18:03:00
>
> --
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender.
> Any offers or quotation of service are subject to formal specification.
> Errors and omissions excepted.  Please note that any views or
> opinions presented in this email are solely those of the author and
> do not necessarily represent those of Lumison. Finally, the
> recipient should check this email and any attachments for the
> presence of viruses.  Lumison accept no liability for any damage
> caused by any virus transmitted by this email.
------- End of Original Message -------


No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.81/2350 - Release Date: 09/07/09 18:03:00

--

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender. Any
offers or quotation of service are subject to formal specification.
Errors and omissions excepted.  Please note that any views or opinions
presented in this email are solely those of the author and do not
necessarily represent those of Lumison.
Finally, the recipient should check this email and any attachments for the
presence of viruses.  Lumison accept no liability for any
damage caused by any virus transmitted by this email.

From rsm at fast-serv.com  Tue Sep  8 07:29:13 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 8 Sep 2009 07:29:13 -0400
Subject: [c-nsp] service-policy on virtual interface
In-Reply-To: <20090908111116.M10856@fast-serv.com>
References: <4AA6324F.4060504@imperial.ac.uk>
	<1252419663.6643.2.camel@abehat.net.rm.dk>
	<20090908103823.M72119@fast-serv.com>
	<B5F945E48C137C49A98BC86DD35939C0156B8685A7@nbg01-exch-01.entlstaff.domain.lumison.net>
	<20090908105205.M98445@fast-serv.com>
	<B5F945E48C137C49A98BC86DD35939C0156B8685B9@nbg01-exch-01.entlstaff.domain.lumison.net>
	<20090908111116.M10856@fast-serv.com>
Message-ID: <20090908112733.M18911@fast-serv.com>

Thanks, I don't want to enable global QOS (queuing) which 'mls qos' will
enable.  The default queues cause all kinds of trouble with our traffic (you
can see details in another topic I created couple months back).

--
Randy
www.FastServ.com

---------- Original Message -----------
From: "Randy McAnally" <rsm at fast-serv.com>
To: Ian MacKinnon <Ian.Mackinnon at lumison.net>, "cisco-nsp at puck.nether.net"
<cisco-nsp at puck.nether.net>
Sent: Tue, 8 Sep 2009 07:13:24 -0400
Subject: Re: [c-nsp] service-policy on virtual interface

> By 'not classify' I meant all of our traffic is in the same default 
> class. Could you verify that 'mls qos' is not needed globally before 
> you can do 'mls qos vlan-based' on an interface?
> 
> Cheers
> 
> --
> Randy
> 
> ---------- Original Message -----------
> From: Ian MacKinnon <Ian.Mackinnon at lumison.net>
> To: Randy McAnally <rsm at fast-serv.com>, "cisco-nsp at puck.nether.net"
> <cisco-nsp at puck.nether.net>
> Sent: Tue, 8 Sep 2009 16:05:57 +0100
> Subject: RE: [c-nsp] service-policy on virtual interface
> 
> > Not seen problems turning on mls qos.
> > We have on the physicals :-
> > Int gi1/1
> > mls qos vlan-based
> > mls qos trust dscp
> > and a typical service policy looks like :-
> > policy-map 10MegPolice
> >   class class-default
> >    police 10000000 26000 32000    conform-action transmit     exceed-
> > action transmit     violate-action drop
> > 
> > what do you mean you don't classify?
> > 
> > Ian
> > 
> > -----Original Message-----
> > From: Randy McAnally [mailto:rsm at fast-serv.com]
> > Sent: 08 September 2009 11:54
> > To: Ian MacKinnon; cisco-nsp at puck.nether.net
> > Subject: RE: [c-nsp] service-policy on virtual interface
> > 
> > 6500 platform.
> > 
> > Last time we had 'mls qos' enabled we had massive speed/packet loss issues
> > with interfaces over 40% utilization since we don't classify traffic.
> > 
> > Is there any possible issues you might see?
> > 
> > --
> > Randy
> > 
> > ---------- Original Message -----------
> > From: Ian MacKinnon <Ian.Mackinnon at lumison.net>
> > To: Randy McAnally <rsm at fast-serv.com>, "cisco-nsp at puck.nether.net"
> > <cisco-nsp at puck.nether.net>
> > Sent: Tue, 8 Sep 2009 15:44:57 +0100
> > Subject: RE: [c-nsp] service-policy on virtual interface
> > 
> > > Hi Randy,
> > > What platform?
> > > On 6500/7600 the answer is yes, you need mls qos vlan-based on the
> > > physical interfaces and then you can police on the SVI.
> > >
> > > Ian
> > >
> > > -----Original Message-----
> > > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> > > bounces at puck.nether.net] On Behalf Of Randy McAnally Sent: 08
> > > September 2009 11:40 To: cisco-nsp at puck.nether.net Subject: [c-nsp]
> > > service-policy on virtual interface
> > >
> > > Do the same commands work e.g. 'service-policy input/output
> > > FooPolicy' at the virtual interface level the same as they do on a
> > > physical port, both in and out?
> > >
> > > I'm trying to set up rate limiting 'further up the line' rather than
> > > at the network edge, so we can pool customer bandwidth and keep
> > > inbound floods of traffic from being passed beyond the distribution layer.
> > >
> > > --
> > > Randy
> > > _______________________________________________
> > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > >
> > > No virus found in this incoming message.
> > > Checked by AVG - www.avg.com
> > >
> > > Version: 8.5.409 / Virus Database: 270.13.81/2350 - Release Date:
> > > 09/07/09 18:03:00
> > >
> > > --
> > >
> > > This email and any files transmitted with it are confidential and intended
> > > solely for the use of the individual or entity to whom they are addressed.
> > > If you have received this email in error please notify the sender.
> > > Any offers or quotation of service are subject to formal specification.
> > > Errors and omissions excepted.  Please note that any views or
> > > opinions presented in this email are solely those of the author and
> > > do not necessarily represent those of Lumison. Finally, the
> > > recipient should check this email and any attachments for the
> > > presence of viruses.  Lumison accept no liability for any damage
> > > caused by any virus transmitted by this email.
> > ------- End of Original Message -------
> > 
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > 
> > Version: 8.5.409 / Virus Database: 270.13.81/2350 - Release Date: 
> > 09/07/09 18:03:00
> > 
> > --
> > 
> > This email and any files transmitted with it are confidential and intended
> > solely for the use of the individual or entity to whom they are addressed.
> > If you have received this email in error please notify the sender. 
> > Any offers or quotation of service are subject to formal specification.
> > Errors and omissions excepted.  Please note that any views or 
> > opinions presented in this email are solely those of the author and 
> > do not necessarily represent those of Lumison. Finally, the 
> > recipient should check this email and any attachments for the 
> > presence of viruses.  Lumison accept no liability for any damage 
> > caused by any virus transmitted by this email.
> ------- End of Original Message -------
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
------- End of Original Message -------


From peter at rathlev.dk  Tue Sep  8 11:52:09 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Tue, 08 Sep 2009 17:52:09 +0200
Subject: [c-nsp] service-policy on virtual interface
In-Reply-To: <20090908112733.M18911@fast-serv.com>
References: <4AA6324F.4060504@imperial.ac.uk>
	<1252419663.6643.2.camel@abehat.net.rm.dk>
	<20090908103823.M72119@fast-serv.com>
	<B5F945E48C137C49A98BC86DD35939C0156B8685A7@nbg01-exch-01.entlstaff.domain.lumison.net>
	<20090908105205.M98445@fast-serv.com>
	<B5F945E48C137C49A98BC86DD35939C0156B8685B9@nbg01-exch-01.entlstaff.domain.lumison.net>
	<20090908111116.M10856@fast-serv.com>
	<20090908112733.M18911@fast-serv.com>
Message-ID: <1252425129.7100.0.camel@abehat.net.rm.dk>

On Tue, 2009-09-08 at 07:29 -0400, Randy McAnally wrote:
> Thanks, I don't want to enable global QOS (queuing) which 'mls qos'
> will enable.  The default queues cause all kinds of trouble with our
> traffic (you can see details in another topic I created couple months
> back).

Why not enable "mls qos" and then reserve all buffer space for the one
queue in use?

-- 
Peter



From vitya at list.ru  Tue Sep  8 12:42:55 2009
From: vitya at list.ru (victor)
Date: Tue, 08 Sep 2009 20:42:55 +0400
Subject: [c-nsp] MPLS-TE and bandwidth reservation
Message-ID: <op.uzx51tm52vrlim@localhost.localdomain>

Hello

I'm experimenting with MPLS-TE and have a question about reservation of  
the bandwidth on an interface. It's more or less clear that each tunnel  
can receive the necessary bandwidth and that it is consequently subtracted  
 from the overall bandwidth configured for the interface. Therefore there  
can only be a finite number of TE-tunnels going through an interface. My  
question is: What will happen if I run a generic IP traffic over this  
interface in addition to  MPLS-TE tunnels? How will this IP flow affect  
creation of new TE tunnels? What will have higher priority (or what will  
be dropped/rerouted first) when the interface bandwidth reaches it's max  
physical capacity?
It seems that with an abundance of information about MPLS I can't find  
neither exact answer to these questions nor the algorithm behind this  
particular process so any references to  white-papers, books, etc are  
greatly appreciated.

Thank you in advance.
Victor.


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From avayner at cisco.com  Tue Sep  8 12:58:58 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Tue, 8 Sep 2009 18:58:58 +0200
Subject: [c-nsp] Change VRF RD
In-Reply-To: <4AA6324F.4060504@imperial.ac.uk>
References: <4AA6324F.4060504@imperial.ac.uk>
Message-ID: <FDD1CDB3FB499E4087CC7670BBCA22C6373385@XMB-AMS-101.cisco.com>

Phil,

Why don't you just create a new VRF, with a new RD, then prepare all the
import/export policies (no need to change RT's). You can also prepare
any relevant PE-CE routing config in advance.
This can be done offline.

Then when you want to migrate the customer, you just change the "ip vrf
forwarding" command on the customer interface, and make the PE-CE
routing work (like wait for the routing protocols to come up).

You can do this migration per customer, and you do not have to do it per
the whole box, so you can basically control the scope of disruption very
easily.

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Phil Mayers
Sent: Tuesday, September 08, 2009 13:31
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Change VRF RD

All,

When we deployed our MPLS core, we made the minor mistake of setting the

RD the same on every router.

On the platform we're using (6500/sup720, 12.2(33)SXI) you don't seem to

be able to change the rd of a defined VRF; you have to "no rd" which 
promptly blows away the "router bgp / address family ipv4 vrf X" as well

as the route-target statements; and it won't let you enter a new rd for 
~60 seconds, claiming:

% Deletion of "rd" in progress; wait for it to complete

This is obviously hugely unhelpful for correcting the mistake.

Does anyone know if this is possible either without an outage or with a 
very short one? Or are we stuck with taking the outage?
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From eng_mssk at hotmail.com  Mon Sep  7 13:20:40 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Mon, 7 Sep 2009 20:20:40 +0300
Subject: [c-nsp] Cisco ACS related
In-Reply-To: <BLU102-W175DDB3F072211A758AD9FAEB0@phx.gbl>
References: <BLU102-W175DDB3F072211A758AD9FAEB0@phx.gbl>
Message-ID: <BLU102-W163F102CD9DA2041BA736BFAEB0@phx.gbl>


 hey all


I have to create authorization shell and define the
commands I want to match or unmacth 

Then I have to assign this set to a group , for example 1
and assign a user to that group

and i have to configure on the device the command aaa authorization config-command



> From: eng_mssk at hotmail.com
> To: cisco-nsp at puck.nether.net
> Date: Mon, 7 Sep 2009 14:32:54 +0300
> Subject: [c-nsp] Cisco ACS related
> 
> 
> can i deny a certain command under configuration mode for certain authorization shell ?
> 
> _________________________________________________________________
> With Windows Live, you can organize, edit, and share your photos.
> http://www.microsoft.com/middleeast/windows/windowslive/products/photo-gallery-edit.aspx
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_________________________________________________________________
Share your memories online with anyone you want.
http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1

From psirt at cisco.com  Tue Sep  8 10:35:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Tue, 08 Sep 2009 10:35:00 -0400
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial of
	Service Vulnerabilities in Multiple Cisco Products
Message-ID: <200909081035.tcp24@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: TCP State Manipulation Denial of Service
Vulnerabilities in Multiple Cisco Products

Advisory ID: cisco-sa-20090908-tcp24

Revision 1.0

For Public Release 2009 September 8 1700 UTC (GMT)

+---------------------------------------------------------------------

Summary
=======

Multiple Cisco products are affected by denial of service (DoS)
vulnerabilities that manipulate the state of Transmission Control
Protocol (TCP) connections. By manipulating the state of a TCP
connection, an attacker could force the TCP connection to remain in a
long-lived state, possibly indefinitely. If enough TCP connections
are forced into a long-lived or indefinite state, resources on a
system under attack may be consumed, preventing new TCP connections
from being accepted. In some cases, a system reboot may be necessary
to recover normal system operation. To exploit these vulnerabilities,
an attacker must be able to complete a TCP three-way handshake with a
vulnerable system.

In addition to these vulnerabilities, Cisco Nexus 5000 devices
contain a TCP DoS vulnerability that may result in a system crash.
This additional vulnerability was found as a result of testing the
TCP state manipulation vulnerabilities.

Cisco has released free software updates for download from the Cisco
website that address these vulnerabilities. Workarounds that mitigate
these vulnerabilities are available.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090908-tcp24.shtml

Affected Products
=================

Vulnerable Products
+------------------

The following Cisco products have a TCP implementation that is
affected by these vulnerabilities. Refer to the Software Versions and
Fixes section for information on fixed software.

Cisco IOS Software

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log into the device and issue the 
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
    Cisco Internetwork Operating System Software
    IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by cisco Systems, Inc.
    Compiled Mon 17-Mar-08 14:39 by dchih
    <output truncated>

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.4(20)T with an installed image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team
    <output truncated>

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link:

http://www.cisco.com/warp/public/620/1.html

Cisco IOS-XE Software

The version of Cisco IOS-XE Software that is running on a Cisco
product can be determined using the "show version" command from the
Command Line Interface (CLI).

Cisco CatOS Software

The version of Cisco CatOS Software that is running on a Cisco
product can be determined using the "show version" command from the
CLI.

Cisco Adaptive Security Appliance (ASA) and Cisco PIX

Cisco ASA and Cisco PIX security appliances running versions 7.0,
7.1, 7.2, 8.0, and 8.1 are affected when configured for any of the
following features:

  * SSL VPNs
  * ASDM Administrative Access
  * Telnet Access
  * SSH Access
  * Cisco Tunneling Control Protocol (cTCP) for Remote Access VPNs
  * Virtual Telnet
  * Virtual HTTP
  * Transport Layer Security (TLS) Proxy for Encrypted Voice
    Inspection
  * Cut-Through Proxy for Network Access

The version of software that is running on a Cisco ASA and Cisco PIX
security appliances can be determined using the "show version" command
from the CLI.

Cisco NX-OS Software

The version of Cisco NX-OS Software that is running on Cisco Nexus
5000 and 7000 series devices can be determined using the "show version"
command from the CLI.

Scientific Atlanta Products

Scientific Atlanta customers are instructed to contact Scientific
Atlanta's Technical Support for questions regarding the impact,
mitigation and remediation of the vulnerabilities discussed in this
document.

Contact information for Scientific Atlanta Technical Support can be
found at the following web site:

http://www.cisco.com/en/US/products/ps10459/serv_group_home.html

Linksys Products

Customers with Linksys products should contact the following email
address for questions regarding the impact, mitigation and
remediation of the vulnerabilities discussed in this document:

security at linksys.com

Products Confirmed Not Vulnerable
+--------------------------------

The following Cisco products are not affected:

  * Cisco IOS XR
  * Cisco IOS Software Modularity
  * Cisco ASA and Cisco PIX Software version 8.2
  * Cisco PIX Software version 6.x and earlier
  * Cisco Firewall Services Module (FWSM)
  * Cisco Multilayer Distribution Switches (MDS)
  * Cisco Application Control Engine (ACE) Modules and Appliances
  * Cisco ACE XML Gateway
  * Cisco Access Control Server (ACS) Solution Engine
  * Cisco Guard
  * Cisco Security Monitoring, Analysis, and Response System (CS-MARS)
  * Cisco ONS 15000
  * Cisco Content Services Switches (CSS)
  * Cisco Wide Area Application Services (WAAS)
  * Cisco Wireless LAN Controller (WLC)
  * IronPort C, M, S and X Series Appliances

Cisco PSIRT tested Cisco products that are based on Linux and
Microsoft Windows operating systems and found that although TCP
connections in a FINWAIT1 state may temporarily consume system
resources the operating systems eventually clear the TCP connections.
If enough system resources are consumed, a sustained DoS condition
may be possible. This outcome is highly dependent on the
configuration and usage of a system. For more information about how
these vulnerabilities affect Microsoft Windows operating systems,
please consult the following Microsoft website at the following link:

http://go.microsoft.com/fwlink/?LinkId=155978

No other Cisco products are currently known to be affected by these
vulnerabilities.

Details
=======

Multiple Cisco products are affected by DoS vulnerabilities in the
TCP protocol. By manipulating the state of TCP connections, an
attacker could force a system that is under attack to maintain TCP
connections for long periods of time, or indefinitely in some cases.
With a sufficient number of open TCP connections, the attacker may be
able to cause a system to consume internal buffer and memory
resources, resulting in new TCP connections being denied access to a
targeted port or an entire system. A system reboot may be required to
restore full system functionality. A full TCP three-way handshake is
required to exploit these vulnerabilities.

Network devices are not directly impacted by TCP state manipulation
DoS attacks transiting a device; however, network devices that
maintain the state of TCP connections may be impacted. If the
attacker can establish enough TCP connections through a transit
device that maintains TCP state, device resources may be exhausted
and prevent the device from processing new TCP connections, resulting
in a DoS condition. If an affected device that forwards traffic (that
is, routes) in a network is the target of a TCP state manipulation
attack, the attacker could cause a network-impacting DoS condition.

Cisco IOS Software

All Cisco IOS Software versions are affected by this vulnerability. A
device running Cisco IOS Software that is under attack will have
numerous hung TCP connections in the FINWAIT1 state. The "show tcp
brief" command can be used to display the hung TCP connections. The
following is example output showing an attack in progress.

    Router#show tcp brief | include FIN
    63D697C4  192.168.1.10.80            192.168.1.20.38479         FINWAIT1
    63032A28  192.168.1.10.80            192.168.1.20.54154         FINWAIT1
    645F8068  192.168.1.10.80            192.168.1.20.56287         FINWAIT1
    630323F4  192.168.1.10.80            192.168.1.20.6372          FINWAIT1
    63D69190  192.168.1.10.80            192.168.1.20.23489         FINWAIT1

The vulnerabilities for Cisco IOS Software are documented in Cisco
Bug ID CSCsv04836.

Cisco IOS-XE Software

All Cisco IOS-XE Software versions are affected by this
vulnerability. A device running Cisco IOS-XE Software that is under
attack will have numerous hung TCP connections in the FINWAIT1 state.
The "show tcp brief" command can be used to display the hung TCP
connections. The following is example output showing an attack in
progress.

    Router#show tcp brief | include FIN
    63D697C4  192.168.1.10.80            192.168.1.20.38479         FINWAIT1
    63032A28  192.168.1.10.80            192.168.1.20.54154         FINWAIT1
    645F8068  192.168.1.10.80            192.168.1.20.56287         FINWAIT1
    630323F4  192.168.1.10.80            192.168.1.20.6372          FINWAIT1
    63D69190  192.168.1.10.80            192.168.1.20.23489         FINWAIT1

The vulnerabilities for Cisco IOS-XE Software are documented in Cisco
Bug ID CSCsv07712.

Cisco CatOS Software

All Cisco CatOS Software versions are affected by these
vulnerabilities. A device running Cisco CatOS Software that is under
attack will have numerous hung TCP connections in the FIN_WAIT_1
state. The "show netstat" command can be used to display the hung TCP
connections. The following is example output showing an attack in
progress.

    Console> (enable) show netstat
    Active Internet connections (including servers)
    Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
    tcp        0     83  192.168.1.10.23        192.168.1.20.46056       FIN_WAIT_1
    tcp        0     83  192.168.1.10.23        192.168.1.20.16305       FIN_WAIT_1
    tcp        0     83  192.168.1.10.23        192.168.1.20.14628       FIN_WAIT_1
    tcp        0     83  192.168.1.10.23        192.168.1.20.7275        FIN_WAIT_1
    tcp        0     83  192.168.1.10.23        192.168.1.20.39559       FIN_WAIT_1

The vulnerabilities for Cisco CatOS Software are documented in Cisco
Bug ID CSCsv66169.

Cisco ASA and Cisco PIX Software

All Cisco ASA and Cisco PIX Software versions are affected by these
vulnerabilities. A device running Cisco ASA and Cisco PIX Software
that is under attack will have numerous TCP connections in the
established state. The "show asp table socket" command can be used to
display the TCP connections. The following is example output showing
a potential attack in progress.

    FIREWALL# show asp table socket | grep ESTAB
    TCP       123a8a6c  192.168.1.10:80           192.168.1.20:46181    ESTAB
    TCP       123e6d54  192.168.1.10:80           192.168.1.20:29546    ESTAB
    TCP       1244f78c  192.168.1.10:80           192.168.1.20:40271    ESTAB
    TCP       124f8d2c  192.168.1.10:80           192.168.1.20:46599    ESTAB
    TCP       12507f2c  192.168.1.10:80           192.168.1.20:5607     ESTAB

It is possible for normal traffic to cause established TCP
connections to appear on Cisco ASA or PIX devices, especially VPN
connections terminated to the device. In order to confirm if
established TCP connections are part of an attack, administrators
should use a monitoring point outside the firewall such as a packet
sniffer or Netflow collection agent to examine the profile of the
suspicious TCP connections and determine if an attack is occurring.

Note: The show asp table socket command was introduced in Cisco ASA
and Cisco PIX Software 8.0(1).

Further detail about hung TCP connections can be found with "show conn
detail all long" command. The IP address used to qualify the example
below is the address of the firewall interface under attack.

    FIREWALL# show conn detail all long | grep 192.168.1.10
    TCP outside:192.168.1.20/62345 (192.168.1.20/62345) NP Identity Ifc:192.168.1.10/80 (192.168.1.10/80), flags UB, idle 0s, uptime 0s, timeout 1m0s, bytes 0
    TCP outside:192.168.1.20/56268 (192.168.1.20/56268) NP Identity Ifc:192.168.1.10/80 (192.168.1.10/80), flags UB, idle 0s, uptime 0s, timeout 1m0s, bytes 0
    TCP outside:192.168.1.20/63445 (192.168.1.20/63445) NP Identity Ifc:192.168.1.10/80 (192.168.1.10/80), flags UB, idle 0s, uptime 0s, timeout 1m0s, bytes 0
    TCP outside:192.168.1.20/49151 (192.168.1.20/49151) NP Identity Ifc:192.168.1.10/80 (192.168.1.10/80), flags UB, idle 0s, uptime 0s, timeout 1m0s, bytes 0
    TCP outside:192.168.1.20/57147 (192.168.1.20/57147) NP Identity Ifc:192.168.1.10/80 (192.168.1.10/80), flags UB, idle 0s, uptime 0s, timeout 1m0s, bytes 0

Note: Both troubleshooting commands referenced about will display TCP
connections that are terminated to a firewall interface and
transiting through the firewall.

The vulnerabilities for Cisco ASA and Cisco PIX Software are
documented in Cisco Bug ID CSCsv02768.

Cisco NX-OS Software

All Cisco Nexus 5000 and 7000 platforms running Cisco NX-OS Software
are affected by these vulnerabilities. A Nexus 5005 or 7000 device
running Cisco NX-OS Software that is under attack will have numerous
hung TCP connections in the FIN_WAIT_1 state. The "show tcp connection
detail" command can be used to display the hung TCP connections. The
following is example output showing an attack in progress.

    NEXUS# show tcp connection detail | include FIN
    
      State: FIN_WAIT_1
      State: FIN_WAIT_1
      State: FIN_WAIT_1
      State: FIN_WAIT_1
      State: FIN_WAIT_1

The hung TCP connection vulnerabilities for Nexus 5000 and Nexus 7000
devices are documented in Cisco Bug ID CSCsv08325 and Cisco Bug ID CSCsv08579
respectively.

While investigating the TCP state manipulation vulnerabilities, it
was discovered that Cisco NX-OS on Nexus 5000 platforms may be
vulnerable to a system crash when receiving a specific sequence of
TCP packets. This vulnerability is documented in Cisco Bug ID 
CSCsv08059 and has been assigned CVE identifier CVE-2009-0627.

The TCP state manipulation vulnerabilities have been assigned Common
Vulnerabilities and Exposures (CVE) identifier CVE-2008-4609.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerabilities in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss

CSCsv04836 - Connections getting stuck at FINWAIT1 state

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

CSCsv07712 - Connections getting stuck at FINWAIT1 state

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

CSCsv66169 - TCP Connections get stuck in FINWAIT1 state

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

CSCsv02768 - TCP connections getting stuck in FINWAIT1 state

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

CSCsv08325 - TCP connections may get stuck in any state after ESTAB indefinitely

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

CSCsv08579 - TCP connections get stuck in FINWAIT1 state indefinitely

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

CSCsv08059 - NEXUS 5000 crashes after certain TCP packets

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the TCP state manipulation vulnerabilities
may result in a DoS condition where new TCP connections are not
accepted on an affected system. Repeated exploitation may result in a
sustained DoS condition. A reboot may be required to recover affected
systems.

In addition, Cisco Nexus 5000 systems may crash upon receiving a
specific sequence of TCP packets.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a
complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Cisco IOS Software

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-----------------------------------------+
|   Major    |  Availability of Repaired  |
|  Release   |          Releases          |
|------------+----------------------------|
|  Affected  | First Fixed  | Recommended |
| 12.0-Based |   Release    |   Release   |
|  Releases  |              |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0       | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0DA     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.0DB     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0DC     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            |              | 12.0(33)S5  |
|            |              |             |
|            | 12.0(33)S3   | 12.0(32)    |
| 12.0S      |              | S14;        |
|            | 12.0(32)S12  | Available   |
|            |              | on          |
|            |              | 25-SEP-2009 |
|------------+--------------+-------------|
|            |              | 12.0(33)S5  |
|            |              |             |
|            | Vulnerable;  | 12.0(32)    |
| 12.0SC     | first fixed  | S14;        |
|            | in 12.0S     | Available   |
|            |              | on          |
|            |              | 25-SEP-2009 |
|------------+--------------+-------------|
|            |              | 12.0(33)S5  |
|            |              |             |
|            | Vulnerable;  | 12.0(32)    |
| 12.0SL     | first fixed  | S14;        |
|            | in 12.0S     | Available   |
|            |              | on          |
|            |              | 25-SEP-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0SP     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            |              | 12.0(33)S5  |
|            |              |             |
|            | Vulnerable;  | 12.0(32)    |
| 12.0ST     | first fixed  | S14;        |
|            | in 12.0S     | Available   |
|            |              | on          |
|            |              | 25-SEP-2009 |
|------------+--------------+-------------|
|            |              | 12.0(33)S5  |
|            |              |             |
|            | Vulnerable;  | 12.0(32)    |
| 12.0SX     | first fixed  | S14;        |
|            | in 12.0S     | Available   |
|            |              | on          |
|            |              | 25-SEP-2009 |
|------------+--------------+-------------|
|            | 12.0(32)SY8  | 12.0(32)    |
|            |              | SY9a        |
|            | 12.0(32)SY9a |             |
| 12.0SY     |              | 12.0(32)    |
|            | 12.0(32)SY10 | SY10;       |
|            | ; Available  | Available   |
|            | on           | on          |
|            | 25-SEP-2009  | 25-SEP-2009 |
|------------+--------------+-------------|
|            |              | 12.0(33)S5  |
|            |              |             |
|            |              | 12.0(32)    |
| 12.0SZ     | 12.0(30)SZ10 | S14;        |
|            |              | Available   |
|            |              | on          |
|            |              | 25-SEP-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0T      | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.0W      | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
| 12.0WC     | first fixed  |             |
|            | in 12.4T     |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0WT     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0XA     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0XB     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0XC     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0XD     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0XE     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
| 12.0XF     | first fixed  |             |
|            | in 12.4      |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0XG     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0XH     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(25b)   |
| 12.0XI     | first fixed  |             |
|            | in 12.4      | 12.4(23b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0XJ     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0XK     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0XL     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0XM     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0XN     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0XQ     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.0XR     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.0XS     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0XT     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.0XV     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|  Affected  | First Fixed  | Recommended |
| 12.1-Based |   Release    |   Release   |
|  Releases  |              |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1       | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1AA     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.1AX     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.1(22)    |
| 12.1AY     | first fixed  | EA13        |
|            | in 12.1EA    |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.1(22)    |
| 12.1AZ     | first fixed  | EA13        |
|            | in 12.1EA    |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1CX     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1DA     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1DB     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1DC     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.1E      | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
| 12.1EA     | 12.1(22)EA13 | 12.1(22)    |
|            |              | EA13        |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.1EB     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.1EC     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.1EO     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.1EU     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1EV     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1EW     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1EX     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
| 12.1EY     | 12.2(44)EY   | 12.2(46)EY  |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1EZ     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1GA     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1GB     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1T      | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XA     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XB     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XC     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XD     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XE     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XF     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XG     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XH     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XI     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XJ     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XL     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XM     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XP     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XQ     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XR     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.1XS     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XT     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XU     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XV     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XW     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XX     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XY     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1XZ     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1YA     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1YB     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1YC     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1YD     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.1YE     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1YF     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.1YH     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.1YI     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.1(22)    |
| 12.1YJ     | first fixed  | EA13        |
|            | in 12.1EA    |             |
|------------+--------------+-------------|
|  Affected  | First Fixed  | Recommended |
| 12.2-Based |   Release    |   Release   |
|  Releases  |              |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2       | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2B      | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2BC     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2BW     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2BX     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2BY     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2BZ     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2CX     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2CY     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            |              | 12.2(28)    |
|            | Vulnerable;  | SB14;       |
| 12.2CZ     | first fixed  | Available   |
|            | in 12.2SB    | on          |
|            |              | 20-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(25b)   |
| 12.2DA     | 12.2(12)DA14 |             |
|            |              | 12.4(23b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2DD     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2DX     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2EW     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2EWA    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2EX     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Releases     |             |
|            | prior to     |             |
|            | 12.2(44)EY   | 12.2(50)SE3 |
|            | are          |             |
| 12.2EY     | vulnerable,  | 12.2(52)SE; |
|            | release 12.2 | Available   |
|            | (44)EY and   | on          |
|            | later are    | 13-OCT-2009 |
|            | not          |             |
|            | vulnerable   |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2EZ     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2FX     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2FY     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2FZ     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2IRA    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2IRB    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
| 12.2IRC    | 12.2(33)IRC  |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
| 12.2IXA    | migrate to   |             |
|            | any release  |             |
|            | in 12.2IXH   |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
| 12.2IXB    | migrate to   |             |
|            | any release  |             |
|            | in 12.2IXH   |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
| 12.2IXC    | migrate to   |             |
|            | any release  |             |
|            | in 12.2IXH   |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
| 12.2IXD    | migrate to   |             |
|            | any release  |             |
|            | in 12.2IXH   |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
| 12.2IXE    | migrate to   |             |
|            | any release  |             |
|            | in 12.2IXH   |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
| 12.2IXF    | migrate to   |             |
|            | any release  |             |
|            | in 12.2IXH   |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
| 12.2IXG    | migrate to   |             |
|            | any release  |             |
|            | in 12.2IXH   |             |
|------------+--------------+-------------|
| 12.2IXH    | 12.2(18)IXH  |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2JA     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2JK     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2MB     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            |              | 12.4(25b)   |
| 12.2MC     | 12.2(15)MC2m |             |
|            |              | 12.4(23b)   |
|------------+--------------+-------------|
|            |              | 12.2(28)    |
|            | Vulnerable;  | SB14;       |
| 12.2S      | first fixed  | Available   |
|            | in 12.2SB    | on          |
|            |              | 20-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.2(31)    |
|            | 12.2(28)SB13 | SB16        |
|            |              |             |
|            | 12.2(31)SB14 | 12.2(28)    |
| 12.2SB     |              | SB14;       |
|            | 12.2(33)SB1b | Available   |
|            |              | on          |
|            | 12.2(34)SB2  | 20-OCT-2009 |
|            |              |             |
|            |              | 12.2(33)SB7 |
|------------+--------------+-------------|
|            |              | 12.2(28)    |
|            | Vulnerable;  | SB14;       |
| 12.2SBC    | first fixed  | Available   |
|            | in 12.2SB    | on          |
|            |              | 20-OCT-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2SCA    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
| 12.2SCB    | 12.2(33)SCB1 | 12.2(33)    |
|            |              | SCB4        |
|------------+--------------+-------------|
|            | 12.2(44)SE5  | 12.2(50)SE3 |
|            |              |             |
| 12.2SE     | 12.2(46)SE2  | 12.2(52)SE; |
|            |              | Available   |
|            | 12.2(50)SE   | on          |
|            |              | 13-OCT-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2SEA    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2SEB    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2SEC    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2SED    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2SEE    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2SEF    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2SEG    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
| 12.2SG     | 12.2(50)SG   | 12.2(53)SG1 |
|------------+--------------+-------------|
|            |              | 12.2(31)    |
|            |              | SGA11;      |
| 12.2SGA    | 12.2(31)SGA9 | Available   |
|            |              | on          |
|            |              | 04-DEC-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2SL     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Releases     |             |
|            | prior to     |             |
|            | 12.2(29)SM5  |             |
|            | are          |             |
| 12.2SM     | vulnerable,  | 12.2(29)SM5 |
|            | release 12.2 |             |
|            | (29)SM5 and  |             |
|            | later are    |             |
|            | not          |             |
|            | vulnerable   |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2SO     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
| 12.2SQ     | 12.2(44)SQ2  |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2SRA    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            |              | 12.2(33)    |
|            |              | SRD3        |
|            |              |             |
| 12.2SRB    | 12.2(33)     | 12.2(33)    |
|            | SRB5a        | SRC5;       |
|            |              | Available   |
|            |              | on          |
|            |              | 29-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.2(33)    |
|            |              | SRC5;       |
| 12.2SRC    | 12.2(33)SRC3 | Available   |
|            |              | on          |
|            |              | 29-OCT-2009 |
|------------+--------------+-------------|
| 12.2SRD    | 12.2(33)SRD1 | 12.2(33)    |
|            |              | SRD3        |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2STE    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2SU     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2SV     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2SVA    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2SVC    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2SVD    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
| 12.2SVE    | 12.2(29)SVE1 |             |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.2SW     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization | 12.2(18)    |
|            | per the      | SXF17;      |
| 12.2SX     | instructions | Available   |
|            | in Obtaining | on          |
|            | Fixed        | 30-SEP-2009 |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization | 12.2(18)    |
|            | per the      | SXF17;      |
| 12.2SXA    | instructions | Available   |
|            | in Obtaining | on          |
|            | Fixed        | 30-SEP-2009 |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization | 12.2(18)    |
|            | per the      | SXF17;      |
| 12.2SXB    | instructions | Available   |
|            | in Obtaining | on          |
|            | Fixed        | 30-SEP-2009 |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization | 12.2(18)    |
|            | per the      | SXF17;      |
| 12.2SXD    | instructions | Available   |
|            | in Obtaining | on          |
|            | Fixed        | 30-SEP-2009 |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization | 12.2(18)    |
|            | per the      | SXF17;      |
| 12.2SXE    | instructions | Available   |
|            | in Obtaining | on          |
|            | Fixed        | 30-SEP-2009 |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            |              | 12.2(18)    |
|            | 12.2(18)     | SXF17;      |
| 12.2SXF    | SXF16        | Available   |
|            |              | on          |
|            |              | 30-SEP-2009 |
|------------+--------------+-------------|
|            |              | 12.2(33)    |
|            |              | SXH6;       |
| 12.2SXH    | 12.2(33)SXH5 | Available   |
|            |              | on          |
|            |              | 30-OCT-2009 |
|------------+--------------+-------------|
| 12.2SXI    | 12.2(33)SXI1 | 12.2SXI2a   |
|------------+--------------+-------------|
|            |              | 12.2(28)    |
|            | Vulnerable;  | SB14;       |
| 12.2SY     | first fixed  | Available   |
|            | in 12.2SB    | on          |
|            |              | 20-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.2(28)    |
|            | Vulnerable;  | SB14;       |
| 12.2SZ     | first fixed  | Available   |
|            | in 12.2SB    | on          |
|            |              | 20-OCT-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2T      | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2TPC    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(25b)   |
| 12.2XA     | first fixed  |             |
|            | in 12.4      | 12.4(23b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XB     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XC     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XD     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XE     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XF     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XG     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XH     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XI     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XJ     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XK     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XL     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XM     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2XN     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Please see   |             |
| 12.2XNA    | Cisco IOS-XE |             |
|            | Software     |             |
|            | Availability |             |
|------------+--------------+-------------|
|            | Please see   |             |
| 12.2XNB    | Cisco IOS-XE |             |
|            | Software     |             |
|            | Availability |             |
|------------+--------------+-------------|
|            | Please see   |             |
| 12.2XNC    | Cisco IOS-XE |             |
|            | Software     |             |
|            | Availability |             |
|------------+--------------+-------------|
|            | Please see   |             |
| 12.2XND    | Cisco IOS-XE |             |
|            | Software     |             |
|            | Availability |             |
|------------+--------------+-------------|
|            |              |             |
|------------+--------------+-------------|
|            |              | 12.2(50)    |
|            |              | SG5;        |
| 12.2XO     | 12.2(52)XO   | Available   |
|            |              | on          |
|            |              | 28-SEP-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XQ     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XR     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XS     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XT     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XU     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XV     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2XW     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2YA     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YB     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YC     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YD     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YE     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YF     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YG     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YH     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YJ     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YK     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YL     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2YM     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YN     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YO     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.2YP     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YQ     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YR     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YS     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YT     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YU     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YV     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YW     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YX     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YY     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2YZ     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization | 12.2(18)    |
|            | per the      | SXF17;      |
| 12.2ZA     | instructions | Available   |
|            | in Obtaining | on          |
|            | Fixed        | 30-SEP-2009 |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2ZB     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2ZC     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2ZD     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2ZE     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2ZF     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2ZG     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2ZH     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2ZJ     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2ZL     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.2ZM     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2ZP     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2ZU     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            |              | 12.2(28)    |
|            | Vulnerable;  | SB14;       |
| 12.2ZX     | first fixed  | Available   |
|            | in 12.2SB    | on          |
|            |              | 20-OCT-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.2ZY     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
| 12.2ZYA    | 12.2(18)ZYA1 | 12.2(18)    |
|            |              | ZYA2        |
|------------+--------------+-------------|
|  Affected  | First Fixed  | Recommended |
| 12.3-Based |   Release    |   Release   |
|  Releases  |              |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(25b)   |
| 12.3       | first fixed  |             |
|            | in 12.4      | 12.4(23b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(25b)   |
| 12.3B      | first fixed  |             |
|            | in 12.4      | 12.4(23b)   |
|------------+--------------+-------------|
|            | 12.3(21a)BC9 | 12.3(21a)   |
| 12.3BC     |              | BC9         |
|            | 12.3(23)BC6  |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3BW     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.3EU     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.3JA     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.3JEA    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.3JEB    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
| 12.3JEC    | 12.3(8)JEC3  |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.3JED    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3JK     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.3JL     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.3JX     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3T      | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.3TPC    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.3VA     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3XA     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.3XB     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3XC     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3XD     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3XE     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.3XF     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3XG     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.2(33)SB7 |
| 12.3XI     | first fixed  |             |
|            | in 12.2SB    | 12.2(31)    |
|            |              | SB16        |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(15)XR7 |
| 12.3XJ     | first fixed  |             |
|            | in 12.4XR    | 12.4(22)XR  |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3XK     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3XL     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3XQ     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3XR     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3XS     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.3XU     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(15)XR7 |
| 12.3XW     | first fixed  |             |
|            | in 12.4XR    | 12.4(22)XR  |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3XX     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3XY     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3XZ     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3YA     | first fixed  |             |
|            | in 12.4      | 12.4(25b)   |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.3YD     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(15)XR7 |
| 12.3YF     | first fixed  |             |
|            | in 12.4XR    | 12.4(22)XR  |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.3YG     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.3YH     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.3YI     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.3YJ     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.3YK     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(23b)   |
| 12.3YM     | 12.3(14)YM13 |             |
|            |              | 12.4(25b)   |
|------------+--------------+-------------|
|            | Vulnerable;  | 12.4(23b)   |
| 12.3YQ     | first fixed  |             |
|            | in 12.4T     | 12.4(25b)   |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.3YS     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.3YT     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.3YU     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)XR7 |
| 12.3YX     | 12.3(14)YX14 |             |
|            |              | 12.4(22)XR  |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.3YZ     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.3ZA     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|  Affected  | First Fixed  | Recommended |
| 12.4-Based |   Release    |   Release   |
|  Releases  |              |             |
|------------+--------------+-------------|
|            | 12.4(18d)    |             |
|            |              | 12.4(25b)   |
| 12.4       | 12.4(23a)    |             |
|            |              | 12.4(23b)   |
|            | 12.4(25)     |             |
|------------+--------------+-------------|
|            | 12.4(22)GC1  |             |
| 12.4GC     |              | 12.4(24)GC1 |
|            | 12.4(24)GC1  |             |
|------------+--------------+-------------|
|            | 12.4(16b)JA1 |             |
| 12.4JA     |              |             |
|            | 12.4(21a)JA  |             |
|------------+--------------+-------------|
| 12.4JDA    | 12.4(10b)    |             |
|            | JDA3         |             |
|------------+--------------+-------------|
| 12.4JDC    | 12.4(10b)JDC |             |
|------------+--------------+-------------|
| 12.4JDD    | 12.4(10b)JDD |             |
|------------+--------------+-------------|
| 12.4JK     | 12.4(3)JK4   |             |
|------------+--------------+-------------|
| 12.4JL     | 12.4(3)JL1   |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.4JMA    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.4JMB    | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
| 12.4JX     | 12.4(21a)JX  |             |
|------------+--------------+-------------|
|            | 12.4(11)MD7  | 12.4(11)MD9 |
|            |              |             |
| 12.4MD     | 12.4(15)MD2  | 12.4(15)MD3 |
|            |              |             |
|            | 12.4(22)MD   | 12.4(22)MD1 |
|------------+--------------+-------------|
| 12.4MDA    | 12.4(22)MDA  | 12.4(22)    |
|            |              | MDA1        |
|------------+--------------+-------------|
| 12.4MR     | 12.4(19)MR2  | 12.4(19)MR3 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            |              |             |
| 12.4SW     | 12.4(15)SW3  | 12.4(22)T3  |
|            |              |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            | 12.4(5)T5e   | 12.4(15)T10 |
|            |              |             |
|            | 12.4(15)T6a  | 12.4(20)T4  |
|            |              |             |
| 12.4T      | 12.4(22)T1   | 12.4(22)T3  |
|            |              |             |
|            | 12.4(20)T2   | 12.4(24)T2; |
|            |              | Available   |
|            | 12.4(24)T    | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.4XA     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.4XB     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.4XC     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            |              |             |
| 12.4XD     | 12.4(4)XD12  | 12.4(22)T3  |
|            |              |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            |              |             |
| 12.4XE     | 12.4(6)XE4   | 12.4(22)T3  |
|            |              |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.4XF     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            |              |             |
| 12.4XG     | 12.4(9)XG4   | 12.4(22)T3  |
|            |              |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.4XJ     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.4XK     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
| 12.4XL     | 12.4(15)XL4  |             |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            |              |             |
| 12.4XM     | 12.4(15)XM3  | 12.4(22)T3  |
|            |              |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.4XN     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.4XP     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            |              |             |
| 12.4XQ     | 12.4(15)XQ2  | 12.4(22)T3  |
|            |              |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            | 12.4(15)XR4  |             |
| 12.4XR     |              | 12.4(15)XR7 |
|            | 12.4(22)XR   |             |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            | Vulnerable;  |             |
| 12.4XT     | first fixed  | 12.4(22)T3  |
|            | in 12.4T     |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            | Vulnerable;  |             |
|            | Contact your |             |
|            | support      |             |
|            | organization |             |
|            | per the      |             |
| 12.4XV     | instructions |             |
|            | in Obtaining |             |
|            | Fixed        |             |
|            | Software     |             |
|            | section of   |             |
|            | this         |             |
|            | advisory     |             |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            |              |             |
| 12.4XW     | 12.4(11)XW10 | 12.4(22)T3  |
|            |              |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(20)T4  |
|            |              |             |
|            |              | 12.4(22)T3  |
| 12.4XY     | 12.4(15)XY4  |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            |              |             |
| 12.4XZ     | 12.4(15)XZ2  | 12.4(22)T3  |
|            |              |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
|            |              | 12.4(15)T10 |
|            |              |             |
|            |              | 12.4(20)T4  |
|            |              |             |
| 12.4YA     | 12.4(20)YA2  | 12.4(22)T3  |
|            |              |             |
|            |              | 12.4(24)T2; |
|            |              | Available   |
|            |              | on          |
|            |              | 23-OCT-2009 |
|------------+--------------+-------------|
| 12.4YB     | 12.4(22)YB   | 12.4(22)YB4 |
|------------+--------------+-------------|
| 12.4YD     | 12.4(22)YD   | 12.4(22)YD1 |
|------------+--------------+-------------|
| 12.4YE     | 12.4(22)YE   | 12.4(22)YE1 |
+-----------------------------------------+

Cisco IOS-XE Software

+---------------------------------------+
| IOS-XE Release | First Fixed Release  |
|----------------+----------------------|
| 2.1.x          | 2.2.3                |
|----------------+----------------------|
| 2.2.x          | 2.2.3                |
|----------------+----------------------|
| 2.3.x          | Not Vulnerable       |
|----------------+----------------------|
| 2.4.x          | Not Vulnerable       |
+---------------------------------------+

Cisco CatOS Software

+---------------------------------------+
|     Affected     |    First Fixed     |
|     Releases     |      Release       |
|------------------+--------------------|
| 7.x              | 7.6(24a)           |
|------------------+--------------------|
| 8.x              | 8.7(2a)            |
+---------------------------------------+

Cisco ASA and Cisco PIX Software

+---------------------------------------+
|     Affected     |    First Fixed     |
|     Releases     |      Release       |
|------------------+--------------------|
| 7.0              | 7.0(8.6)           |
|------------------+--------------------|
| 7.1              | 7.1(2.81)          |
|------------------+--------------------|
| 7.2              | 7.2(4.30)          |
|------------------+--------------------|
| 8.0              | 8.0(4.28)          |
|------------------+--------------------|
| 8.1              | 8.1(2.19)          |
|------------------+--------------------|
| 8.2              | Not Vulnerable     |
+---------------------------------------+

Cisco NX-OS Software

+---------------------------------------+
|     Affected     |    First Fixed     |
|     Releases     |      Release       |
|------------------+--------------------|
| Cisco Nexus 5000 | 4.0(1a)N2(1)       |
|------------------+--------------------|
| Cisco Nexus 7000 | 4.1(4)             |
+---------------------------------------+

Workarounds
===========

It is possible to mitigate these vulnerabilities with the following
workarounds.

Cisco IOS Software

The Cisco Guide to Harden Cisco IOS Devices provides examples of many
useful techniques to mitigate against the TCP state manipulation
vulnerabilities. These include:

  * Infrastructure Access Control Lists (iACL)
  * Receive Access Control Lists (rACL)
  * Transit Access Control Lists (tACL)
  * VTY Access Control Lists
  * Control Plane Policing (CoPP)
  * Control Plane Protection (CPPr)
  * Management Plane Policing (MPP)

For more information on the topics listed above, consult the Cisco
Guide to Harden Cisco IOS Devices at the following link:

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml

Cisco CatOS Software

Cisco CatOS software provides VLAN Access Control Lists (VACL) to
mitigate against the TCP state manipulation vulnerabilities. For more
information on configuring VACLs on CatOS 7.x software versions,
please consult the following link:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/catos/7.x/configuration/guide/acc_list.html

For more information on configuring VACLs on CatOS 8.x software
versions, please consult the following link:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/catos/8.x/configuration/guide/acc_list.html

Cisco ASA and Cisco PIX Software

Cisco ASA and Cisco PIX Software provide a method to expire stalled
half-closed TCP connections that helps mitigate against the TCP state
manipulation vulnerabilities. This method protects against attacks
directed to a firewall and devices protected by a firewall. The 
"timeout half-closed" command will expire TCP sessions that have
remained in a half-closed state beyond a user-configured timeout.

    FIREWALL(config)# timeout half-closed 0:5:0

This command will set the TCP half-closed timeout to the smallest
permitted value of five minutes. For more information on the TCP
half-closed timeout, please consult the following link:

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/t.html#wp1500148

Cisco Nexus Software

Cisco Nexus software provides several ACL methods to mitigate against
the TCP state manipulation vulnerabilities. For more information on
configuring ACLs on Nexus 5000 systems, please consult the following
link:

http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli_rel_4_0_1a/sec_ipacls.html

For more information on configuring ACLs on Nexus 7000 systems,
please consult the following link:

http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_1/nx-os/security/configuration/guide/sec_nx-os-cfg.html

Cisco Applied Mitigation Bulletin

Additional mitigations that can be deployed on Cisco devices within
the network are available in the Cisco Applied Mitigation Bulletin
companion document for this advisory, which is available at the
following link:

http://www.cisco.com/warp/public/707/cisco-amb-20090908-tcp24.shtml

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at:

http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html

or as otherwise set forth at Cisco.com Downloads at:

http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at:

http://www.cisco.com

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to:
http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html

for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

The TCP state manipulation vulnerabilities were reported to Cisco by
Robert E. Lee and Jack Louis of Outpost24. The Cisco Nexus 5000
vulnerability was discovered by Cisco.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20090908-tcp24.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+----------------------------------------+
| Revision |                   | Initial |
| 1.0      | 2009-September-08 | public  |
|          |                   | release |
+----------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and
registering to receive security information from Cisco, is available
on Cisco's worldwide website at:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

This includes instructions for press inquiries regarding Cisco
security notices. All Cisco security advisories are available at:

http://www.cisco.com/go/psirt
-----BEGIN PGP SIGNATURE-----

iD8DBQFKpmqc86n/Gc8U/uARArnQAJ4iK9a4jII3ItWKUvAVgQo0N6KAfgCcDc1i
05+ITgtJJF8WI4iOrovU2Ik=
=cUrI
-----END PGP SIGNATURE-----

From NMaio at guesswho.com  Tue Sep  8 16:39:40 2009
From: NMaio at guesswho.com (NMaio at guesswho.com)
Date: Tue, 8 Sep 2009 13:39:40 -0700
Subject: [c-nsp] Opensource Websense Alternative
Message-ID: <2AA600764E54964491083B1E0EC81A301241712AD6@EXCLUS.nationala-1advertising.com>

Does anybody know of an open source alternative to Websense or Secure Computing Smartfilter?  Transparent proxying with Squid works but we would like something like url filtering through a Websense equivalent box.
Thanks in advance.
Nick


From asturluismi at gmail.com  Tue Sep  8 13:39:53 2009
From: asturluismi at gmail.com (luismi)
Date: Tue, 08 Sep 2009 19:39:53 +0200
Subject: [c-nsp] Leaking specific routes from a VRF
In-Reply-To: <001101ca2f9d$8289f290$879dd7b0$@com>
References: <9445a3fb0909011149p1e744ecatf30cf3434d92aa2e@mail.gmail.com>
	<001101ca2f9d$8289f290$879dd7b0$@com>
Message-ID: <1252431593.19566.0.camel@dsba-ipso>

Thanks for all the emails, we have created some code here with
success :-D

Thanks agains to everyone for the time and attention.


From jp at saucer.midcoast.com  Tue Sep  8 13:40:20 2009
From: jp at saucer.midcoast.com (jp)
Date: Tue, 8 Sep 2009 13:40:20 -0400
Subject: [c-nsp] MIBs and OIDs
In-Reply-To: <BLU102-W1504B0EAECC087779DB264FAEB0@phx.gbl>
References: <BLU102-W1504B0EAECC087779DB264FAEB0@phx.gbl>
Message-ID: <20090908174019.GA13065@saucer.midcoast.com>

http://www.ks-soft.net/hostmon.eng/mibbrowser/index.htm

is what I use. It's a windows program, but it works fine in wine.

On Mon, Sep 07, 2009 at 11:36:23AM +0300, Mohammad Khalil wrote:
> 
> hey all 
> what is the way to transform the MIBs to OIDs ?
> 
> _________________________________________________________________
> Show them the way! Add maps and directions to your party invites. 
> http://www.microsoft.com/windows/windowslive/products/events.aspx
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
/*
Jason Philbrook   |   Midcoast Internet Solutions - Wireless and DSL
    KB1IOJ        |   Broadband Internet Access, Dialup, and Hosting 
 http://f64.nu/   |   for Midcoast Maine    http://www.midcoast.com/
*/

From panocisco77 at gmail.com  Tue Sep  8 14:49:13 2009
From: panocisco77 at gmail.com (Renelson Panosky)
Date: Tue, 8 Sep 2009 14:49:13 -0400
Subject: [c-nsp] CCNA Voice
Message-ID: <16e2ac180909081149l6fef266bt1677c7529951620c@mail.gmail.com>

I am studying for my CCNA Voice and i am having a lot of trouble with the
call leg set up arrow, if anybody here can help i will greatly appreciate
it.

1) Phone 1234 dials a PSTN Destination 405-555-0103
2) Provide call setup in both directions

Panocisco

From yanf787 at yahoo.com  Tue Sep  8 14:47:59 2009
From: yanf787 at yahoo.com (Yan Filyurin)
Date: Tue, 8 Sep 2009 11:47:59 -0700 (PDT)
Subject: [c-nsp] MPLS-TE and bandwidth reservation
In-Reply-To: <op.uzx51tm52vrlim@localhost.localdomain>
References: <op.uzx51tm52vrlim@localhost.localdomain>
Message-ID: <589623.76220.qm@web58703.mail.re1.yahoo.com>

I am actually verifying if any new features have been released, that might allow tunnel setups and re-optimization to work based on actual available bandwidth, based on actual load, but assuming you are using OSPF or IS-IS CSPF during the set up and optimization, it will take all the information and for each link it will evaluate its eligibility based on the bandwidth that was reserved vs. the bandwidth that is reservable, so if you have an interface of 100 Mbps and you have 10% of it as RSVP reservable and then a percentage of it reserved, then you have only the remains of that available. In other words if you run regular IP traffic, it will not be subject to RSVP reservations and will not be used in calculations, so if you overload the link with it, the tunnels will still stay up. Just like you can overload the link by sending all kinds of traffic through the tunnels (that do not automatically adjust), but bandwidth that you reserve will be less than
 what you are sending out. And set up and holding priority is what you can use to keep the tunnels where they are, but unless bandwidth is reserved the mechanism does not know about its use. 

Check out the NANOG web site for a bunch of presentations and the best book, which is the TE classic is Traffic Engineering with MPLS by Eric Osborne and I like MPLS Fundamentals by Luc De Gein. Reading some stuff on RSVP would be great too, but it will put anyone to sleep. 

Yan




________________________________
From: victor <vitya at list.ru>
To: cisco-nsp at puck.nether.net
Cc: cisco-nsp at puck.nether.net
Sent: Tuesday, September 8, 2009 12:42:55 PM
Subject: [c-nsp] MPLS-TE and bandwidth reservation

Hello

I'm experimenting with MPLS-TE and have a question about reservation of the bandwidth on an interface. It's more or less clear that each tunnel can receive the necessary bandwidth and that it is consequently subtracted from the overall bandwidth configured for the interface. Therefore there can only be a finite number of TE-tunnels going through an interface. My question is: What will happen if I run a generic IP traffic over this interface in addition to  MPLS-TE tunnels? How will this IP flow affect creation of new TE tunnels? What will have higher priority (or what will be dropped/rerouted first) when the interface bandwidth reaches it's max physical capacity?
It seems that with an abundance of information about MPLS I can't find neither exact answer to these questions nor the algorithm behind this particular process so any references to  white-papers, books, etc are greatly appreciated.

Thank you in advance.
Victor.


--Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



      

From yanf787 at yahoo.com  Tue Sep  8 14:47:59 2009
From: yanf787 at yahoo.com (Yan Filyurin)
Date: Tue, 8 Sep 2009 11:47:59 -0700 (PDT)
Subject: [c-nsp] MPLS-TE and bandwidth reservation
In-Reply-To: <op.uzx51tm52vrlim@localhost.localdomain>
References: <op.uzx51tm52vrlim@localhost.localdomain>
Message-ID: <589623.76220.qm@web58703.mail.re1.yahoo.com>

I am actually verifying if any new features have been released, that might allow tunnel setups and re-optimization to work based on actual available bandwidth, based on actual load, but assuming you are using OSPF or IS-IS CSPF during the set up and optimization, it will take all the information and for each link it will evaluate its eligibility based on the bandwidth that was reserved vs. the bandwidth that is reservable, so if you have an interface of 100 Mbps and you have 10% of it as RSVP reservable and then a percentage of it reserved, then you have only the remains of that available. In other words if you run regular IP traffic, it will not be subject to RSVP reservations and will not be used in calculations, so if you overload the link with it, the tunnels will still stay up. Just like you can overload the link by sending all kinds of traffic through the tunnels (that do not automatically adjust), but bandwidth that you reserve will be less than
 what you are sending out. And set up and holding priority is what you can use to keep the tunnels where they are, but unless bandwidth is reserved the mechanism does not know about its use. 

Check out the NANOG web site for a bunch of presentations and the best book, which is the TE classic is Traffic Engineering with MPLS by Eric Osborne and I like MPLS Fundamentals by Luc De Gein. Reading some stuff on RSVP would be great too, but it will put anyone to sleep. 

Yan




________________________________
From: victor <vitya at list.ru>
To: cisco-nsp at puck.nether.net
Cc: cisco-nsp at puck.nether.net
Sent: Tuesday, September 8, 2009 12:42:55 PM
Subject: [c-nsp] MPLS-TE and bandwidth reservation

Hello

I'm experimenting with MPLS-TE and have a question about reservation of the bandwidth on an interface. It's more or less clear that each tunnel can receive the necessary bandwidth and that it is consequently subtracted from the overall bandwidth configured for the interface. Therefore there can only be a finite number of TE-tunnels going through an interface. My question is: What will happen if I run a generic IP traffic over this interface in addition to  MPLS-TE tunnels? How will this IP flow affect creation of new TE tunnels? What will have higher priority (or what will be dropped/rerouted first) when the interface bandwidth reaches it's max physical capacity?
It seems that with an abundance of information about MPLS I can't find neither exact answer to these questions nor the algorithm behind this particular process so any references to  white-papers, books, etc are greatly appreciated.

Thank you in advance.
Victor.


--Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



      

From malitsky at netabn.com  Tue Sep  8 17:12:01 2009
From: malitsky at netabn.com (Michael Malitsky)
Date: Tue, 8 Sep 2009 16:12:01 -0500
Subject: [c-nsp] Catalyst vs. Nexus
Message-ID: <79AF0C3901752A49881FE4CB31F7AA40016ECE50@abn-borg2.NETABN.LOCAL>

Hello,

I am working on the first 10Gig deployment in a small data center.  Main
driver is a SQL database, so there will be a bunch of SQL servers
virtualized using VMware, running against a SAN over iSCSI.

I've done some research and it looks like I can build the network using
a Catalyst 4900M or a Nexus 5010, at about the same cost.  I am familiar
with the Catalyst family, but have no experience with the Nexus.  At
this point, the only major difference I see is that Nexus supports Fibre
Channel (which I don't need).  For being different product families, I
am having a hard time understanding what the major differences are.  Can
anyone enlighten me?  
If anyone has hands-on experience with both and willing to share, that
would be most appreciated.

Thanks,
Michael Malitsky



From malitsky at netabn.com  Tue Sep  8 17:13:28 2009
From: malitsky at netabn.com (Michael Malitsky)
Date: Tue, 8 Sep 2009 16:13:28 -0500
Subject: [c-nsp] Geographically dispersed ASA failover?
In-Reply-To: <1251929106.2923.11.camel@abehat.net.rm.dk>
References: <79AF0C3901752A49881FE4CB31F7AA40016ECC39@abn-borg2.NETABN.LOCAL>
	<1251929106.2923.11.camel@abehat.net.rm.dk>
Message-ID: <79AF0C3901752A49881FE4CB31F7AA40016ECE51@abn-borg2.NETABN.LOCAL>

Thanks to all who replied, will give it a try.

Sincerely,
Michael


> -----Original Message-----
> From: Peter Rathlev [mailto:peter at rathlev.dk]
> Sent: Wednesday, September 02, 2009 5:05 PM
> To: Michael Malitsky
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Geographically dispersed ASA failover?
> 
> On Wed, 2009-09-02 at 11:38 -0500, Michael Malitsky wrote:
> > Does anyone know if the ASA failover feature supports a setup where
> the
> > ASAs are in geographically different locations?  Specifically, I
have
> > two data centers about 30 miles apart, connected by a 50Mb metro
> > ethernet link with latency under 10ms.
> 
> I think you'll be fine. We're currently running a pair of ASAs in
> failover with ~40 km LoS between them (RTT ~0.7 ms) without the
> slightest problems at all. It traverses a mix of 1Gig and 10Gig links.
> 
> Regards,
> Peter
> 


From ibrahim.abozaid at gmail.com  Tue Sep  8 17:21:14 2009
From: ibrahim.abozaid at gmail.com (Ibrahim Abo Zaid)
Date: Wed, 9 Sep 2009 00:21:14 +0300
Subject: [c-nsp] ISIS Adj-filter problem
In-Reply-To: <003301ca3083$d595e520$80c1af60$@com>
References: <a48927f70908191440x7c1d0a36u995e6a759758731b@mail.gmail.com>
	<4AA6483D.9080102@mtnbusiness.co.za>
	<003301ca3083$d595e520$80c1af60$@com>
Message-ID: <a48927f70909081421na7be37kb989359e93db0da5@mail.gmail.com>

Thanks Victor

but why applying the filter on all routers except DIS solves the problem ?
is there any explainsion


best regards
--Ibrahim

On Tue, Sep 8, 2009 at 3:56 PM, Victor Cappuccio <vcappucc at cisco.com> wrote:

> Hi,
>
> Did you tried the same command but not on the DIS??  On a LAN, one of the
> routers elects itself the DIS, based on interface priority (the default is
> 64). If all interface priorities are the same, the router with the highest
> subnetwork point of attachment (SNPA) is selected
>
> I did your same configuration, but now I applied the filter to all the
> router but the DIS.
>
> R2 in this case is the DIS!
>
> R2#show run int f0/0
> Building configuration...
>
> Current configuration : 132 bytes
> !
> interface FastEthernet0/0
>  ip address 10.10.123.2 255.255.255.0
>  ip router isis
>  duplex auto
>  speed auto
>  isis priority 127
> end
>
> R2#show clns neigh
>
> System Id      Interface   SNPA                State  Holdtime  Type
> Protocol
> R3             Fa0/0       c003.163c.0000      Up     25        L1   IS-IS
> R1             Fa0/0       c001.163c.0000      Up     29        L1   IS-IS
> R2#show clns is-
>
> System Id      Interface   State  Type Priority  Circuit Id         Format
> R3             Fa0/0       Up     L1   64        R2.01              Phase V
> R1             Fa0/0       Up     L1   64        R2.01              Phase V
> R2#
>
> R2#show ip route isis
>      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
> i L1    10.10.3.3/32 [115/10] via 10.10.123.3, FastEthernet0/0
> i L1    10.10.1.1/32 [115/10] via 10.10.123.1, FastEthernet0/0
>
>
> ---
>
> R1#show run int f0/0
> Building configuration...
>
> Current configuration : 140 bytes
> !
> interface FastEthernet0/0
>  ip address 10.10.123.1 255.255.255.0
>  ip router isis
>  duplex auto
>  speed auto
>  isis adjacency-filter R2
> end
>
> R1#show run | in clns filter
> clns filter-set R2 permit 49.0001.0000.0000.0002.00
> R1#show isis neigh
>
> System Id      Type Interface IP Address      State Holdtime Circuit Id
> R2             L1   Fa0/0     10.10.123.2     UP    9        R2.01
> R1#show ip route isis
>      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
> i L1    10.10.2.2/32 [115/10] via 10.10.123.2, FastEthernet0/0
> R1#
>
> ----
>
>
> R3#show run int f0/0
> Building configuration...
>
> Current configuration : 140 bytes
> !
> interface FastEthernet0/0
>  ip address 10.10.123.3 255.255.255.0
>  ip router isis
>  duplex auto
>  speed auto
>  isis adjacency-filter R2
> end
>
> R3#show run | in clns filter
> clns filter-set R2 permit 49.0001.0000.0000.0002.00
> R3#show clns neigh
>
> System Id      Interface   SNPA                State  Holdtime  Type
> Protocol
> R2             Fa0/0       c002.163c.0000      Up     7         L1   IS-IS
> R3#
> R3#show clns is-neighbors
>
> System Id      Interface   State  Type Priority  Circuit Id         Format
> R2             Fa0/0       Up     L1   127       R2.01              Phase V
> R3#show ip route isis
>      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
> i L1    10.10.2.2/32 [115/10] via 10.10.123.2, FastEthernet0/0
> R3#
>
>
> Thanks,
>
> Victor Cappuccio.-
> vcappucc at cisco.com
> CCIE(R/S) #20657
> STAC Support Engineer
> Cisco Small Business Support.
>
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Dave Kruger
> Sent: martes, 08 de septiembre de 2009 15:04
> To: Ibrahim Abo Zaid
> Cc: cisco_nsp
> Subject: Re: [c-nsp] ISIS Adj-filter problem
>
> Hi there
>
> have u managed to figure out what was causing that?
>
> Did you see that your clns filter references
>
> 49.0001.0000.0000.0100.00
>
>
> where as your R1 router's Sys ID is
>
> 49.0001.0000.0000.0001.00
>
>
> Regards,
> Dave
>
> Ibrahim Abo Zaid wrote:
> > Hi All
> >
> > I was testing ISIS Adj-filter option , R1,R2 and R3 are connected over
> > ethernet switch (using dynamips) with the below configuration
> >
> > the configuration works for adj point and both R2 and R3 have ADJ with R1
> > only , the problem is R2 is droping R1 and R3 LSPs and debug shows it is
> > dropped due to invalid adj . can you help to resolve that ?
> >
> > Configuration
> >
> > R1
> > interface Loopback0
> >  ip address 10.10.1.1 255.255.255.255
> > !
> > interface FastEthernet0/0
> >  ip address 10.10.123.1 255.255.255.0
> >  ip router isis
> >
> > router isis
> >  net
> >
>
> >  is-type level-1
> >  passive-interface Loopback0
> >
> > R2
> > interface Loopback0
> >  ip address 10.10.2.2 255.255.255.255
> > !
> > interface FastEthernet0/0
> >  ip address 10.10.123.2 255.255.255.0
> >  ip router isis
> >  isis adjacency-filter A1
> > !
> >   router isis
> >  net 49.0001.0000.0000.0002.00
> >  is-type level-1
> >  passive-interface Loopback0
> >
> > clns filter-set A1 permit 49.0001.0000.0000.0100.00
> >
> > R3
> >
> > interface Loopback0
> >  ip address 10.10.3.3 255.255.255.255
> > !
> > interface FastEthernet0/0
> >  ip address 10.10.123.3 255.255.255.0
> >  ip router isis
> >  isis adjacency-filter A1
> >
> >
> > router isis
> >  net 49.0001.0000.0000.0003.00
> >  is-type level-1
> >  passive-interface Loopback0
> >
> >  clns filter-set A1 permit 49.0001.0000.0000.0100.00
> >
> >
> > verification
> >
> >
> > R1#sh clns neighbors
> > System Id      Interface   SNPA                State  Holdtime  Type
> > Protocol
> > R2             Fa0/0       c201.0544.0000      Up     8         L1
> IS-IS
> > R3             Fa0/0       c202.0544.0000      Up     7         L1
> IS-IS
> >
> > R1 has R2 and R3 LSPs
> >
> > R1#sh isis database
> > IS-IS Level-1 Link State Database:
> > LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime
> ATT/P/OL
> > R1.00-00            * 0x00000010   0x2D88        849               0/0/0
> > R2.00-00              0x00000009   0x8037        1036              0/0/0
> > R2.01-00              0x00000003   0x78D8        1036              0/0/0
> > R3.00-00              0x00000005   0x4470        552               0/0/0
> > R3.01-00              0x00000006   0x78D3        1091              0/0/0
> >
> > but has R3-Lo0 route ONLY !!
> >
> > R1#sh ip route isis
> >      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
> > i L1    10.10.3.3/32 [115/10] via 10.10.123.3, FastEthernet0/0
> >
> > R2#sh clns neighbors
> > System Id      Interface   SNPA                State  Holdtime  Type
> > Protocol
> > R1             Fa0/0       c200.0544.0000      Up     21        L1
> IS-IS
> >
> > R2 don't have R1 and R3 LSPs !!!
> >
> >
> > R2#sh isis database
> > IS-IS Level-1 Link State Database:
> > LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime
> ATT/P/OL
> > R2.00-00            * 0x00000009   0x8037        985               0/0/0
> > R2.01-00            * 0x00000003   0x78D8        986               0/0/0
> >
> > NO ISIS Route  , it normal no LSP :)
> > R2#sh ip route isis
> > R2#
> >
> > R3
> >
> > R3#sh clns neighbors
> > System Id      Interface   SNPA                State  Holdtime  Type
> > Protocol
> > R1             Fa0/0       c200.0544.0000      Up     26        L1
> IS-IS
> >
> > R3#sh isis database
> > IS-IS Level-1 Link State Database:
> > LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime
> ATT/P/OL
> > R1.00-00              0x00000013   0x278B        1181              0/0/0
> > R2.00-00              0x00000009   0x8037        845               0/0/0
> > R2.01-00              0x00000003   0x78D8        846               0/0/0
> > R3.00-00            * 0x00000006   0x4271        1186              0/0/0
> > R3.01-00            * 0x00000007   0x76D4        1185              0/0/0
> >
> > route to R1-Lo0 only !!
> >
> > R3#sh ip route isis
> >      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
> > i L1    10.10.1.1/32 [115/10] via 10.10.123.1, FastEthernet0/0
> >
> > debug isis update-packets shows update is dropped due to invalid ADJ
> >
> >
> > *Mar  1 00:30:16.751: ISIS-Upd: Invalid adjacency
> > *Mar  1 00:30:26.619: ISIS-Upd: Invalid adjacency
> > *Mar  1 00:30:34.151: ISIS-Upd: Invalid adjacency
> >
> > any ideas
> >
> > best regards
> > --Ibrahim
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>

From darrin.machay at yjtsolutions.com  Tue Sep  8 17:36:41 2009
From: darrin.machay at yjtsolutions.com (Darrin Machay)
Date: Tue, 8 Sep 2009 16:36:41 -0500
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <79AF0C3901752A49881FE4CB31F7AA40016ECE50@abn-borg2.NETABN.LOCAL>
References: <79AF0C3901752A49881FE4CB31F7AA40016ECE50@abn-borg2.NETABN.LOCAL>
Message-ID: <2D662A4566A3C2418F7FFE23F90BAAEF0474E81D@yjt01ex01.yjtsolutions.com>

Other than FCoE, the major difference is L3 switching. The 5010 is a
Layer2-only device and the 4900M can do routing. If you're trying to
shave off microseconds, the 5010 will beat the 4900M in switching
latency. On the other hand, the 4900M is modular and well suited for
mixed, low-density 1gig/10gig deployments.


Darrin Machay

YJT Solutions
440 South LaSalle St, Suite 3990
Chicago, IL 60605
Office: 312-362-4712
Cell: 312-961-6977
Darrin.Machay at YJTSolutions.com
www.YJTSolutions.com 



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Michael Malitsky
Sent: Tuesday, September 08, 2009 4:12 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Catalyst vs. Nexus

Hello,

I am working on the first 10Gig deployment in a small data center.  Main
driver is a SQL database, so there will be a bunch of SQL servers
virtualized using VMware, running against a SAN over iSCSI.

I've done some research and it looks like I can build the network using
a Catalyst 4900M or a Nexus 5010, at about the same cost.  I am familiar
with the Catalyst family, but have no experience with the Nexus.  At
this point, the only major difference I see is that Nexus supports Fibre
Channel (which I don't need).  For being different product families, I
am having a hard time understanding what the major differences are.  Can
anyone enlighten me?  
If anyone has hands-on experience with both and willing to share, that
would be most appreciated.

Thanks,
Michael Malitsky


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From frnkblk at iname.com  Tue Sep  8 17:42:58 2009
From: frnkblk at iname.com (Frank Bulk)
Date: Tue, 8 Sep 2009 16:42:58 -0500
Subject: [c-nsp] Opensource Websense Alternative
In-Reply-To: <2AA600764E54964491083B1E0EC81A301241712AD6@EXCLUS.nationala-1advertising.com>
References: <2AA600764E54964491083B1E0EC81A301241712AD6@EXCLUS.nationala-1advertising.com>
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAADeGZobYf/4QoV2PVZQaQ9EAQAAAAA=@iname.com>

That would be Untangle: http://www.untangle.com

Frank

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of NMaio at guesswho.com
Sent: Tuesday, September 08, 2009 3:40 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Opensource Websense Alternative

Does anybody know of an open source alternative to Websense or Secure
Computing Smartfilter?  Transparent proxying with Squid works but we would
like something like url filtering through a Websense equivalent box.
Thanks in advance.
Nick

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From clinton at scripty.com  Tue Sep  8 18:23:24 2009
From: clinton at scripty.com (Clinton Work)
Date: Tue, 08 Sep 2009 16:23:24 -0600
Subject: [c-nsp] Catalyst 4500/Sup5 - carrier-delay supported?
Message-ID: <4AA6D95C.7000706@scripty.com>


I'm trying to figure out of the Catalyst 4500s running Sup5 with IOS 
12.2SG support the carrier-delay command. The interface capabilities 
show that the old Catalyst link debounce feature isn't supported on 
WS-X4306 GigE interfaces , however the switch allows you to configure 
carrier-delay.  For example:

conf t
interface g5/5
carrier-delay msec 100
end

According to the 12.2(46)SG configuration guide, you can only configure 
link debounce on 10GE interfaces.   I can't find any references to 
support for carrier-delay.  

*http://tinyurl.com/m7wvfs*


switch# show int g4/4 cap
GigabitEthernet4/4
  Model:                 WS-X4306-GB-Gbic
  Type:                  1000BaseLH
  Speed:                 1000
  Duplex:                full
  Auto-MDIX:             no
  Trunk encap. type:     802.1Q,ISL
  Trunk mode:            on,off,desirable,nonegotiate
  Channel:               yes
  Broadcast suppression: percentage(0-100), hw
  Flowcontrol:           rx-(off,on,desired),tx-(off,on,desired)
  VLAN Membership:       static, dynamic
  Fast Start:            yes
  Queuing:               rx-(N/A), tx-(1p3q1t, Sharing/Shaping)
  CoS rewrite:           yes
  ToS rewrite:           yes
  Inline power:          no
  SPAN:                  source/destination
  UDLD:                  yes
  Link Debounce:         no
  Link Debounce Time:    no
  Port Security:         yes
  Dot1x:                 yes
  Maximum MTU:           9198 bytes (Jumbo Frames)
  Multiple Media Types:  no
  Diagnostic Monitoring: no


From jabley at hopcount.ca  Tue Sep  8 18:36:31 2009
From: jabley at hopcount.ca (Joe Abley)
Date: Tue, 8 Sep 2009 18:36:31 -0400
Subject: [c-nsp] small cisco as ethernet bridge, IPv6 broken, sadness
Message-ID: <CBABDD85-7831-45A1-8F80-09BF5DFAEDCA@hopcount.ca>

I have the following setup in place for remote access to an exchange  
point in Toronto:

  juniper J2320 router
          |
     cisco bridge 1
          |
          |          ) telco-provided
   -------|-------   ) layer-2
          |          ) transport
          |
     cisco bridge 2
          |
     exchange point
          |
      peer router

The telco transport in question is DSL at the top and ethernet at the  
bottom. The top bridge is connecting local ethernet to ethernet over  
ATM over whatever, so it's a glorified DSL modem; the bottom bridge is  
there to clean the traffic that would otherwise flood to the exchange  
(e.g. to eliminate other weird, foreign-sourced frames that seem to  
appear from the telco layer-2 service from time to time).

For IPv4, this all works gloriously.

For IPv6, not at all.

The bridges are both cisco 2600 devices with "no ip routing". Some  
config fragments below. The top bridge has a DSL WIC and I'm bridging  
between that and a VLAN configured on an FE port; the bottom bridge  
has a pair of FE ports, and I'm bridging between them with no VLANs.  
There is a single BVI configured on "cisco bridge 2" just to give me  
an address to ssh to. I tried removing that and managing the box via  
the console, but no change.

Is there something fundamental I'm missing, here? Why should a  
transparent bridge behave differently with IPv4 than it does with IPv6?


Joe

! cisco bridge 1

cisco 2620 (MPC860) processor (revision 0x102) with 61440K/4096K bytes  
of memory.
System image file is "flash:c2600-ik9o3s3-mz.123-26.bin"

interface ATM0/0
  no ip address
  no ip route-cache
  no atm ilmi-keepalive
  dsl operating-mode auto
!
interface ATM0/0.1 point-to-point
  no ip route-cache
  bridge-group 1
  pvc 0/35
   encapsulation aal5snap
  !
!
interface FastEthernet0/0.200
  encapsulation dot1Q 200
  no ip route-cache
  bridge-group 1
  bridge-group 1 spanning-disabled
!
bridge 1 protocol ieee


! cisco bridge 2

cisco 2621 (MPC860) processor (revision 0x102) with 61440K/4096K bytes  
of memory.
System image file is "flash:c2600-ik9o3s3-mz.123-26.bin"

interface FastEthernet0/0
  description facing the telco
  speed 100
  full-duplex
  bridge-group 1
  bridge-group 1 spanning-disabled
!
interface FastEthernet0/1
  description facing the exchange point
  bridge-group 1
  bridge-group 1 output-pattern-list 1100
  bridge-group 1 spanning-disabled
!
interface BVI1
  description a way to manage the bridge, v4-only is fine
  ip address x.x.x.x y.y.y.y
!
bridge 1 protocol ieee
bridge 1 route ip


From mksmith at adhost.com  Tue Sep  8 18:47:17 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Tue, 8 Sep 2009 15:47:17 -0700
Subject: [c-nsp] small cisco as ethernet bridge, IPv6 broken, sadness
In-Reply-To: <CBABDD85-7831-45A1-8F80-09BF5DFAEDCA@hopcount.ca>
References: <CBABDD85-7831-45A1-8F80-09BF5DFAEDCA@hopcount.ca>
Message-ID: <17838240D9A5544AAA5FF95F8D52031606AFC377@ad-exh01.adhost.lan>

Hello Joe: 

<snip>
> 
> Is there something fundamental I'm missing, here? Why should a
> transparent bridge behave differently with IPv4 than it does with
IPv6?
> 
> 
> Joe
> 
> ! cisco bridge 1
> 
> cisco 2620 (MPC860) processor (revision 0x102) with 61440K/4096K bytes
> of memory.
> System image file is "flash:c2600-ik9o3s3-mz.123-26.bin"
> 
> interface ATM0/0
>   no ip address
>   no ip route-cache
>   no atm ilmi-keepalive
>   dsl operating-mode auto
> !
> interface ATM0/0.1 point-to-point
>   no ip route-cache
>   bridge-group 1
>   pvc 0/35
>    encapsulation aal5snap
>   !
> !
> interface FastEthernet0/0.200
>   encapsulation dot1Q 200
>   no ip route-cache
>   bridge-group 1
>   bridge-group 1 spanning-disabled
> !
> bridge 1 protocol ieee
> 
> 
> ! cisco bridge 2
> 
> cisco 2621 (MPC860) processor (revision 0x102) with 61440K/4096K bytes
> of memory.
> System image file is "flash:c2600-ik9o3s3-mz.123-26.bin"
> 
> interface FastEthernet0/0
>   description facing the telco
>   speed 100
>   full-duplex
>   bridge-group 1
>   bridge-group 1 spanning-disabled
> !
> interface FastEthernet0/1
>   description facing the exchange point
>   bridge-group 1
>   bridge-group 1 output-pattern-list 1100
>   bridge-group 1 spanning-disabled
> !
> interface BVI1
>   description a way to manage the bridge, v4-only is fine
>   ip address x.x.x.x y.y.y.y
> !
> bridge 1 protocol ieee
> bridge 1 route ip
> 

I don't think the bridge is really transparent due to the 'bridge 1
route ip' on your exchange-point side device.  If possible, you might
want to try removing that statement (if you're local to the device, of
course) to see if that does it.  I don't think there is a 'bridge 1
route ipv6'.

Regards,

Mike

From td_miles at yahoo.com  Tue Sep  8 19:05:34 2009
From: td_miles at yahoo.com (Tony)
Date: Tue, 8 Sep 2009 16:05:34 -0700 (PDT)
Subject: [c-nsp] Change VRF RD
In-Reply-To: <4AA6324F.4060504@imperial.ac.uk>
Message-ID: <223123.33641.qm@web110105.mail.gq1.yahoo.com>

Hi,

--- On Tue, 8/9/09, Phil Mayers <p.mayers at imperial.ac.uk> wrote:

> When we deployed our MPLS core, we made the minor mistake
> of setting the RD the same on every router.
> 

I'm curious, I thought setting the RD the same on each PE router (obviously per VPN) was the way to do things ?

Most of the stuff I've seen shows it done this way, eg.

http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00800a6c11.shtml

http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a008009445c.shtml

http://wiki.nil.com/wk/images/b/b1/MPLS_VPN_cheatsheet.pdf


When do/should you set the RD to be different ? I'm guessing it's going to be for larger installations and to allow more customisation or something ?

Happy to do some reading and educate myself if people can point me towards the correct material.


Thanks very much,
Tony.

(apologies for hijacking the thread)


      __________________________________________________________________________________
Get more done like never before with Yahoo!7 Mail.
Learn more: http://au.overview.mail.yahoo.com/


From patrick_mcevilly at harvard.edu  Tue Sep  8 18:48:01 2009
From: patrick_mcevilly at harvard.edu (McEvilly, Patrick )
Date: Tue, 08 Sep 2009 18:48:01 -0400
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <2D662A4566A3C2418F7FFE23F90BAAEF0474E81D@yjt01ex01.yjtsolutions.com>
References: <79AF0C3901752A49881FE4CB31F7AA40016ECE50@abn-borg2.NETABN.LOCAL>
	<2D662A4566A3C2418F7FFE23F90BAAEF0474E81D@yjt01ex01.yjtsolutions.com>
Message-ID: <4AA6DF21.2000107@harvard.edu>

The Nexus 5K does not support VTP.  That may or may not be a issue for you.

Patrick.

Darrin Machay wrote:
> Other than FCoE, the major difference is L3 switching. The 5010 is a
> Layer2-only device and the 4900M can do routing. If you're trying to
> shave off microseconds, the 5010 will beat the 4900M in switching
> latency. On the other hand, the 4900M is modular and well suited for
> mixed, low-density 1gig/10gig deployments.
> 
> 
> Darrin Machay
> 
> YJT Solutions
> 440 South LaSalle St, Suite 3990
> Chicago, IL 60605
> Office: 312-362-4712
> Cell: 312-961-6977
> Darrin.Machay at YJTSolutions.com
> www.YJTSolutions.com 
> 
> 
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Michael Malitsky
> Sent: Tuesday, September 08, 2009 4:12 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Catalyst vs. Nexus
> 
> Hello,
> 
> I am working on the first 10Gig deployment in a small data center.  Main
> driver is a SQL database, so there will be a bunch of SQL servers
> virtualized using VMware, running against a SAN over iSCSI.
> 
> I've done some research and it looks like I can build the network using
> a Catalyst 4900M or a Nexus 5010, at about the same cost.  I am familiar
> with the Catalyst family, but have no experience with the Nexus.  At
> this point, the only major difference I see is that Nexus supports Fibre
> Channel (which I don't need).  For being different product families, I
> am having a hard time understanding what the major differences are.  Can
> anyone enlighten me?  
> If anyone has hands-on experience with both and willing to share, that
> would be most appreciated.
> 
> Thanks,
> Michael Malitsky
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From rocrowe at cisco.com  Tue Sep  8 19:30:35 2009
From: rocrowe at cisco.com (Robert Crowe (rocrowe))
Date: Tue, 8 Sep 2009 19:30:35 -0400
Subject: [c-nsp] Change VRF RD
In-Reply-To: <223123.33641.qm@web110105.mail.gq1.yahoo.com>
References: <4AA6324F.4060504@imperial.ac.uk>
	<223123.33641.qm@web110105.mail.gq1.yahoo.com>
Message-ID: <9C192798F2F9454381E4811C41A4413408F0D595@xmb-rtp-20a.amer.cisco.com>

The main benefit of having a different RD per VRF per PE is for IBGP multipath in the core. If you don't need or ever foresee using/benefiting from multipath, then you can use the same RD for a given VRF on all PE's.

Thanks,


Solutions Architect
SP Mobility Advanced Services
CCIE R&S

Cisco Systems, Inc.
Office: 919-392-1574? Mobile: 919-323-9972
Pager: 800-365-4578? Fax: 919-287-2664
Email: rocrowe at cisco.com
?


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tony
Sent: September 08, 2009 7:06 PM
To: cisco-nsp at puck.nether.net; Phil Mayers
Subject: Re: [c-nsp] Change VRF RD

Hi,

--- On Tue, 8/9/09, Phil Mayers <p.mayers at imperial.ac.uk> wrote:

> When we deployed our MPLS core, we made the minor mistake of setting 
> the RD the same on every router.
> 

I'm curious, I thought setting the RD the same on each PE router (obviously per VPN) was the way to do things ?

Most of the stuff I've seen shows it done this way, eg.

http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00800a6c11.shtml

http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a008009445c.shtml

http://wiki.nil.com/wk/images/b/b1/MPLS_VPN_cheatsheet.pdf


When do/should you set the RD to be different ? I'm guessing it's going to be for larger installations and to allow more customisation or something ?

Happy to do some reading and educate myself if people can point me towards the correct material.


Thanks very much,
Tony.

(apologies for hijacking the thread)


      __________________________________________________________________________________
Get more done like never before with Yahoo!7 Mail.
Learn more: http://au.overview.mail.yahoo.com/

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From peter at rathlev.dk  Tue Sep  8 19:38:15 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Wed, 09 Sep 2009 01:38:15 +0200
Subject: [c-nsp] Change VRF RD
In-Reply-To: <223123.33641.qm@web110105.mail.gq1.yahoo.com>
References: <223123.33641.qm@web110105.mail.gq1.yahoo.com>
Message-ID: <1252453095.3256.34.camel@abehat.net.rm.dk>

On Tue, 2009-09-08 at 16:05 -0700, Tony wrote:
> I'm curious, I thought setting the RD the same on each PE router
> (obviously per VPN) was the way to do things ?
...
> When do/should you set the RD to be different ? I'm guessing it's
> going to be for larger installations and to allow more customisation
> or something ?

The main difference (AFAIK) is that in a route reflector setup, your RR
will reflect all the different routes as long as all the PEs use
different RDs. This in turn means that each RR client (PE) will need
more memory to hold all possible prefixes, but on the other hand they
will be able to use one of the alternative paths immediately upon
discovering that the current best path is invalid, e.g. by the BGP next
hop for the current best path disappearing from the IGP.

With the same RD on all PEs your route reflector will only reflect the
current best path. When this invalidates you have to wait for the RR to
select a new best path and update the RR clients. In the mean time
traffic is black-holed.

So basically: Faster convergence in a route reflector setup.

-- 
Peter



From td_miles at yahoo.com  Tue Sep  8 20:02:51 2009
From: td_miles at yahoo.com (Tony)
Date: Tue, 8 Sep 2009 17:02:51 -0700 (PDT)
Subject: [c-nsp] service-policy on virtual interface
In-Reply-To: <20090908112733.M18911@fast-serv.com>
Message-ID: <452396.77085.qm@web110108.mail.gq1.yahoo.com>

Hi Randy,

I remember the previous topic because I was the one who suggested that you disable QOS globally (if you didn't need it) when you were seeing throughput issues. I stand by this as the easiest solution at the time, but now that you need to use QOS for something else, you'll have to look at the queueing and work out what is happening and how to fix it.

If you don't classify any of your traffic the it will all be in the default class (ie. DSCP & COS = 0) and go into the queue for this class.

What happens depends on what hardware you have. As an example, if you have a 6516-GE-TX card then the following happens you enable QOS. If you run the command "show queueing int gigx/y" you will see something like this:

  Default COS is 0
    Queueing Mode In Tx direction: mode-cos
    Transmit queues [type = 1p2q2t]:
    Queue Id    Scheduling  Num of thresholds
    -----------------------------------------
       1         WRR low             2
       2         WRR high            2
       3         Priority            1

    WRR bandwidth ratios:  100[queue 1] 255[queue 2]
    queue-limit ratios:     70[queue 1]  15[queue 2]  15[Pri Queue]*same as Q2

    queue random-detect-min-thresholds
    ----------------------------------
      1    40[1] 70[2]
      2    40[1] 70[2]

    queue random-detect-max-thresholds
    ----------------------------------
      1    70[1] 100[2]
      2    70[1] 100[2]

    queue thresh cos-map
    ---------------------------------------
    1     1      0 1
    1     2      2 3
    2     1      4 6
    2     2      7
    3     1      5


From this we can see:

Number of queues = 3 (2 normal/configurable + 1 priority)
Number of thresholds per queue = 2 thresholds (except PQ, which has just 1)

You can see from the COS-MAP (or maybe you can't) that COS 0 & 1 are assigned to queue 1, threshold 1.
The real problem is the random-detect thresholds on the queue. What this means is that once the queue gets full above the min-threshold the box will start random throwing out packets (based on queue weightings and number of packets in queues). When the queue gets above max-threshold then all packets for this queue with the COS value will be dropped. This is done to ensure there is some space in the queues for higher priority packets.

From the card above you can see that unclassified traffic (COS 0) will start getting discarded at 40% and as the queue gets fuller it will progressively discard more. If the queue gets to 70% then ALL COS0 traffic will be discarded. In queue 1 this 30% at the top of the queue is for COS 2 & 3 packets in threshold 2.

This theoretically means that the maximum throughput you would see on the above card with just enabling QOS and not configuring anything is around 700Mbps (70% of 1Gbps). in reality it would probably be a bit less, but that would be absolute maximum

You can change this behaviour with the commands:

 wrr-queue random-detect min-threshold
 wrr-queue random-detect max-threshold

(you'll have to read the syntax for the commands, you need to put queue and thresholds on them)

I'm using this card as an example because I have one in a box I can play with, you'll need to adjust it for your particular situation. All of the above is for TX queues, you may also have to adjust the RX queues. 


Now you can see why I previously said the easier option was just to disable QOS ;)


regards,
Tony.



--- On Tue, 8/9/09, Randy McAnally <rsm at fast-serv.com> wrote:

> From: Randy McAnally <rsm at fast-serv.com>
> Subject: Re: [c-nsp] service-policy on virtual interface
> To: "Randy McAnally" <rsm at fast-serv.com>, "Ian MacKinnon" <Ian.Mackinnon at lumison.net>, "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Received: Tuesday, 8 September, 2009, 9:29 PM
> Thanks, I don't want to enable global
> QOS (queuing) which 'mls qos' will
> enable.  The default queues cause all kinds of trouble
> with our traffic (you
> can see details in another topic I created couple months
> back).
> 
> --
> Randy
> www.FastServ.com
> 
> ---------- Original Message -----------
> From: "Randy McAnally" <rsm at fast-serv.com>
> To: Ian MacKinnon <Ian.Mackinnon at lumison.net>,
> "cisco-nsp at puck.nether.net"
> <cisco-nsp at puck.nether.net>
> Sent: Tue, 8 Sep 2009 07:13:24 -0400
> Subject: Re: [c-nsp] service-policy on virtual interface
> 
> > By 'not classify' I meant all of our traffic is in the
> same default 
> > class. Could you verify that 'mls qos' is not needed
> globally before 
> > you can do 'mls qos vlan-based' on an interface?
> > 
> > Cheers
> > 
> > --
> > Randy
> > 
> > ---------- Original Message -----------
> > From: Ian MacKinnon <Ian.Mackinnon at lumison.net>
> > To: Randy McAnally <rsm at fast-serv.com>,
> "cisco-nsp at puck.nether.net"
> > <cisco-nsp at puck.nether.net>
> > Sent: Tue, 8 Sep 2009 16:05:57 +0100
> > Subject: RE: [c-nsp] service-policy on virtual
> interface
> > 
> > > Not seen problems turning on mls qos..
> > > We have on the physicals :-
> > > Int gi1/1
> > > mls qos vlan-based
> > > mls qos trust dscp
> > > and a typical service policy looks like :-
> > > policy-map 10MegPolice
> > >   class class-default
> > >    police 10000000 26000 32000 
>   conform-action transmit 
>    exceed-
> > > action transmit 
>    violate-action drop
> > > 
> > > what do you mean you don't classify?
> > > 
> > > Ian
> > > 
> > > -----Original Message-----
> > > From: Randy McAnally [mailto:rsm at fast-serv.com]
> > > Sent: 08 September 2009 11:54
> > > To: Ian MacKinnon; cisco-nsp at puck.nether.net
> > > Subject: RE: [c-nsp] service-policy on virtual
> interface
> > > 
> > > 6500 platform.
> > > 
> > > Last time we had 'mls qos' enabled we had massive
> speed/packet loss issues
> > > with interfaces over 40% utilization since we
> don't classify traffic.
> > > 
> > > Is there any possible issues you might see?
> > > 
> > > --
> > > Randy
> > > 
> > > ---------- Original Message -----------
> > > From: Ian MacKinnon <Ian.Mackinnon at lumison.net>
> > > To: Randy McAnally <rsm at fast-serv.com>,
> "cisco-nsp at puck.nether.net"
> > > <cisco-nsp at puck.nether.net>
> > > Sent: Tue, 8 Sep 2009 15:44:57 +0100
> > > Subject: RE: [c-nsp] service-policy on virtual
> interface
> > > 
> > > > Hi Randy,
> > > > What platform?
> > > > On 6500/7600 the answer is yes, you need mls
> qos vlan-based on the
> > > > physical interfaces and then you can police
> on the SVI.
> > > >
> > > > Ian
> > > >
> > > > -----Original Message-----
> > > > From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-
> > > > bounces at puck.nether..net]
> On Behalf Of Randy McAnally Sent: 08
> > > > September 2009 11:40 To: cisco-nsp at puck.nether.net
> Subject: [c-nsp]
> > > > service-policy on virtual interface
> > > >
> > > > Do the same commands work e.g.
> 'service-policy input/output
> > > > FooPolicy' at the virtual interface level
> the same as they do on a
> > > > physical port, both in and out?
> > > >
> > > > I'm trying to set up rate limiting 'further
> up the line' rather than
> > > > at the network edge, so we can pool customer
> bandwidth and keep
> > > > inbound floods of traffic from being passed
> beyond the distribution layer.
> > > >
> > > > --
> > > > Randy
> > > >
> _______________________________________________
> > > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > > https://puck..nether.net/mailman/listinfo/cisco-nsp
> > > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > >
> > > > No virus found in this incoming message.
> > > > Checked by AVG - www.avg.com
> > > >
> > > > Version: 8.5.409 / Virus Database:
> 270.13.81/2350 - Release Date:
> > > > 09/07/09 18:03:00
> > > >
> > > > --
> > > >
> > > > This email and any files transmitted with it
> are confidential and intended
> > > > solely for the use of the individual or
> entity to whom they are addressed.
> > > > If you have received this email in error
> please notify the sender.
> > > > Any offers or quotation of service are
> subject to formal specification.
> > > > Errors and omissions excepted.  Please
> note that any views or
> > > > opinions presented in this email are solely
> those of the author and
> > > > do not necessarily represent those of
> Lumison. Finally, the
> > > > recipient should check this email and any
> attachments for the
> > > > presence of viruses.  Lumison accept no
> liability for any damage
> > > > caused by any virus transmitted by this
> email.
> > > ------- End of Original Message -------


      __________________________________________________________________________________
Get more done like never before with Yahoo!7 Mail.
Learn more: http://au.overview.mail.yahoo.com/


From NMaio at guesswho.com  Tue Sep  8 20:27:34 2009
From: NMaio at guesswho.com (NMaio at guesswho.com)
Date: Tue, 8 Sep 2009 20:27:34 -0400
Subject: [c-nsp] Opensource Websense Alternative
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAADeGZobYf/4QoV2PVZQaQ9EAQAAAAA=@iname.com>
References: <2AA600764E54964491083B1E0EC81A301241712AD6@EXCLUS.nationala-1advertising.com>,
	<!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAADeGZobYf/4QoV2PVZQaQ9EAQAAAAA=@iname.com>
Message-ID: <2AA600764E54964491083B1E0EC81A301241757E27@EXCLUS.nationala-1advertising.com>

Frank,
Thanks for the link though this is an inline solution which would be problematic.  
Thank you for the suggestion though.
Nick


________________________________________
From: Frank Bulk [frnkblk at iname.com]
Sent: Tuesday, September 08, 2009 5:42 PM
To: Nicholas Maio; cisco-nsp at puck.nether.net
Subject: RE: Opensource Websense Alternative

That would be Untangle: http://www.untangle.com

Frank

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of NMaio at guesswho.com
Sent: Tuesday, September 08, 2009 3:40 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Opensource Websense Alternative

Does anybody know of an open source alternative to Websense or Secure
Computing Smartfilter?  Transparent proxying with Squid works but we would
like something like url filtering through a Websense equivalent box.
Thanks in advance.
Nick

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From arla at rn.dk  Wed Sep  9 03:00:03 2009
From: arla at rn.dk (Arne Larsen / Region Nordjylland)
Date: Wed, 9 Sep 2009 09:00:03 +0200
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <79AF0C3901752A49881FE4CB31F7AA40016ECE50@abn-borg2.NETABN.LOCAL>
References: <79AF0C3901752A49881FE4CB31F7AA40016ECE50@abn-borg2.NETABN.LOCAL>
Message-ID: <8D68760F464FFD40A01BF2FB374E4A2801CC1C850C57@SRVEXC02.aas.its.nja.dk>

Hi Michael.

The difference between Nexus and an normal Catalyst is the nexus is an cut-though switch where the catalyst is an store-and forward. we use Nexus for backup service.
I can recommend using Nexus, it works fine, and it's fastere. The interface is a bit different but not much. I'll say you'll get it running real fast.

/Arne 

-----Oprindelig meddelelse-----
Fra: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] P? vegne af Michael Malitsky
Sendt: 8. september 2009 23:12
Til: cisco-nsp at puck.nether.net
Emne: [c-nsp] Catalyst vs. Nexus

Hello,

I am working on the first 10Gig deployment in a small data center.  Main driver is a SQL database, so there will be a bunch of SQL servers virtualized using VMware, running against a SAN over iSCSI.

I've done some research and it looks like I can build the network using a Catalyst 4900M or a Nexus 5010, at about the same cost.  I am familiar with the Catalyst family, but have no experience with the Nexus.  At this point, the only major difference I see is that Nexus supports Fibre Channel (which I don't need).  For being different product families, I am having a hard time understanding what the major differences are.  Can anyone enlighten me?  
If anyone has hands-on experience with both and willing to share, that would be most appreciated.

Thanks,
Michael Malitsky


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From avayner at cisco.com  Wed Sep  9 04:08:50 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Wed, 9 Sep 2009 10:08:50 +0200
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <79AF0C3901752A49881FE4CB31F7AA40016ECE50@abn-borg2.NETABN.LOCAL>
References: <79AF0C3901752A49881FE4CB31F7AA40016ECE50@abn-borg2.NETABN.LOCAL>
Message-ID: <FDD1CDB3FB499E4087CC7670BBCA22C63734D4@XMB-AMS-101.cisco.com>

Michael,

I suggest you take a look here:
http://www.cisco.com/en/US/products/ps9441/Products_Sub_Category_Home.ht
ml

Basically the whole Nexus family is running a different OS (NX-OS) which
is based on the MDS storage OS line.
http://www.cisco.com/en/US/products/ps9372/index.html

There are a few differences between Catalyst switches and Nexus
switches.

For example, Nexus supports vPC, which means that you have a
multi-chassis EtherChannel trunk from a pair of Nexus 5000/7000
distribution switches to any EtherChannel enabled access switch. This
basically doubles the Access->Distribution bandwidth as you have no
links blocked by Spanning Tree.

Another major difference is the integration of Nexus 2000 Fabric
Extenders with Nexus 5000 switches. The Nexus 2000 switches basically
act as remote (over 10Gig fiber) "linecards" of the Nexus 5000. This
allows deploying top of the rack switches without the additional
management overhead:
http://www.cisco.com/en/US/products/ps10110/index.html

Hope this helps.

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Michael Malitsky
Sent: Wednesday, September 09, 2009 00:12
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Catalyst vs. Nexus

Hello,

I am working on the first 10Gig deployment in a small data center.  Main
driver is a SQL database, so there will be a bunch of SQL servers
virtualized using VMware, running against a SAN over iSCSI.

I've done some research and it looks like I can build the network using
a Catalyst 4900M or a Nexus 5010, at about the same cost.  I am familiar
with the Catalyst family, but have no experience with the Nexus.  At
this point, the only major difference I see is that Nexus supports Fibre
Channel (which I don't need).  For being different product families, I
am having a hard time understanding what the major differences are.  Can
anyone enlighten me?  
If anyone has hands-on experience with both and willing to share, that
would be most appreciated.

Thanks,
Michael Malitsky


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From avayner at cisco.com  Wed Sep  9 04:13:10 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Wed, 9 Sep 2009 10:13:10 +0200
Subject: [c-nsp] small cisco as ethernet bridge, IPv6 broken, sadness
In-Reply-To: <CBABDD85-7831-45A1-8F80-09BF5DFAEDCA@hopcount.ca>
References: <CBABDD85-7831-45A1-8F80-09BF5DFAEDCA@hopcount.ca>
Message-ID: <FDD1CDB3FB499E4087CC7670BBCA22C63734E2@XMB-AMS-101.cisco.com>

Joe,

Did you check for MTU issues?
IPv6 has different MTU requirements than IPv4, and the setup you are
describing is prone to MTU issues due to the reduced MTU on the L2
transport.

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Joe Abley
Sent: Wednesday, September 09, 2009 01:37
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] small cisco as ethernet bridge, IPv6 broken, sadness

I have the following setup in place for remote access to an exchange  
point in Toronto:

  juniper J2320 router
          |
     cisco bridge 1
          |
          |          ) telco-provided
   -------|-------   ) layer-2
          |          ) transport
          |
     cisco bridge 2
          |
     exchange point
          |
      peer router

The telco transport in question is DSL at the top and ethernet at the  
bottom. The top bridge is connecting local ethernet to ethernet over  
ATM over whatever, so it's a glorified DSL modem; the bottom bridge is  
there to clean the traffic that would otherwise flood to the exchange  
(e.g. to eliminate other weird, foreign-sourced frames that seem to  
appear from the telco layer-2 service from time to time).

For IPv4, this all works gloriously.

For IPv6, not at all.

The bridges are both cisco 2600 devices with "no ip routing". Some  
config fragments below. The top bridge has a DSL WIC and I'm bridging  
between that and a VLAN configured on an FE port; the bottom bridge  
has a pair of FE ports, and I'm bridging between them with no VLANs.  
There is a single BVI configured on "cisco bridge 2" just to give me  
an address to ssh to. I tried removing that and managing the box via  
the console, but no change.

Is there something fundamental I'm missing, here? Why should a  
transparent bridge behave differently with IPv4 than it does with IPv6?


Joe

! cisco bridge 1

cisco 2620 (MPC860) processor (revision 0x102) with 61440K/4096K bytes  
of memory.
System image file is "flash:c2600-ik9o3s3-mz.123-26.bin"

interface ATM0/0
  no ip address
  no ip route-cache
  no atm ilmi-keepalive
  dsl operating-mode auto
!
interface ATM0/0.1 point-to-point
  no ip route-cache
  bridge-group 1
  pvc 0/35
   encapsulation aal5snap
  !
!
interface FastEthernet0/0.200
  encapsulation dot1Q 200
  no ip route-cache
  bridge-group 1
  bridge-group 1 spanning-disabled
!
bridge 1 protocol ieee


! cisco bridge 2

cisco 2621 (MPC860) processor (revision 0x102) with 61440K/4096K bytes  
of memory.
System image file is "flash:c2600-ik9o3s3-mz.123-26.bin"

interface FastEthernet0/0
  description facing the telco
  speed 100
  full-duplex
  bridge-group 1
  bridge-group 1 spanning-disabled
!
interface FastEthernet0/1
  description facing the exchange point
  bridge-group 1
  bridge-group 1 output-pattern-list 1100
  bridge-group 1 spanning-disabled
!
interface BVI1
  description a way to manage the bridge, v4-only is fine
  ip address x.x.x.x y.y.y.y
!
bridge 1 protocol ieee
bridge 1 route ip

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From bjorn at mork.no  Wed Sep  9 04:56:36 2009
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Wed, 09 Sep 2009 10:56:36 +0200
Subject: [c-nsp] small cisco as ethernet bridge, IPv6 broken, sadness
In-Reply-To: <CBABDD85-7831-45A1-8F80-09BF5DFAEDCA@hopcount.ca> (Joe Abley's
	message of "Tue, 8 Sep 2009 18:36:31 -0400")
References: <CBABDD85-7831-45A1-8F80-09BF5DFAEDCA@hopcount.ca>
Message-ID: <87tyzcwl6j.fsf@nemi.mork.no>

Joe Abley <jabley at hopcount.ca> writes:

> interface FastEthernet0/1
>  description facing the exchange point
>  bridge-group 1
>  bridge-group 1 output-pattern-list 1100

And this access list does allow e.g. IPv6 multicast frames?


Bj?rn

From nick at inex.ie  Wed Sep  9 06:12:17 2009
From: nick at inex.ie (Nick Hilliard)
Date: Wed, 09 Sep 2009 11:12:17 +0100
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <FDD1CDB3FB499E4087CC7670BBCA22C63734D4@XMB-AMS-101.cisco.com>
References: <79AF0C3901752A49881FE4CB31F7AA40016ECE50@abn-borg2.NETABN.LOCAL>
	<FDD1CDB3FB499E4087CC7670BBCA22C63734D4@XMB-AMS-101.cisco.com>
Message-ID: <4AA77F81.7000208@inex.ie>

On 09/09/2009 09:08, Arie Vayner (avayner) wrote:
> There are a few differences between Catalyst switches and Nexus
> switches.

The nexus n5k / n2k switches are a completely different architecture which 
use different software.  I haven't played with them, but they show promise.

> Another major difference is the integration of Nexus 2000 Fabric
> Extenders with Nexus 5000 switches. The Nexus 2000 switches basically
> act as remote (over 10Gig fiber) "linecards" of the Nexus 5000. This
> allows deploying top of the rack switches without the additional
> management overhead:

The N2K only support 1000 connections, not 10/100.  So if you have slower 
speed kit like console servers or tiny boxes or whatever, you will need to 
cope with these separately.  This is noted obliquely in the documentation:

> http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps10110/data_sheet_c78-507093.html

> Layer 2 Features
[...]
> ? Autonegotiation to 1000BASE-T; full duplex on host interfaces

Nick

From rdobbins at arbor.net  Wed Sep  9 06:51:53 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Wed, 9 Sep 2009 17:51:53 +0700
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <4AA77F81.7000208@inex.ie>
References: <79AF0C3901752A49881FE4CB31F7AA40016ECE50@abn-borg2.NETABN.LOCAL>
	<FDD1CDB3FB499E4087CC7670BBCA22C63734D4@XMB-AMS-101.cisco.com>
	<4AA77F81.7000208@inex.ie>
Message-ID: <23C4445A-6018-4F58-BB94-0F8F32A7472D@arbor.net>


On Sep 9, 2009, at 5:12 PM, Nick Hilliard wrote:

> The nexus n5k / n2k switches are a completely different architecture  
> which use different software.  I haven't played with them, but they  
> show promise.


One caveat to be aware of is that they don't support NetFlow, so your  
network telemetry needs must be met at other points in the topology.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

Sorry, sometimes I mistake your existential crises for technical
insights.

			-- xkcd #625


From nick at inex.ie  Wed Sep  9 06:50:47 2009
From: nick at inex.ie (Nick Hilliard)
Date: Wed, 09 Sep 2009 11:50:47 +0100
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <1F1F2AF9CD74144CAB1F5702D4F74A4E02E2E5F7@PHSXMB24.partners.org>
References: <1F1F2AF9CD74144CAB1F5702D4F74A4E02E2E5F7@PHSXMB24.partners.org>
Message-ID: <4AA78887.3000804@inex.ie>

On 09/09/2009 11:43, Todd, Douglas M. wrote:
> 1) MPLS the 7K is VRF Light syle

it's EARL8, so it's mpls capable at a hardware level.

> 3) Nexus STP is RSTP not pvst+

The N5K supports pvst+:

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/data_sheet_c78-461802.html

> 	OSPF is configured mostly under the interface (passive-interface,
> process # vs globally)

That's a change for the better.  The IOS style ospfv2 configuration is all 
wrong.

Nick

From DTODD at PARTNERS.ORG  Wed Sep  9 06:43:02 2009
From: DTODD at PARTNERS.ORG (Todd, Douglas M.)
Date: Wed, 9 Sep 2009 06:43:02 -0400
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <4AA77F81.7000208@inex.ie>
Message-ID: <1F1F2AF9CD74144CAB1F5702D4F74A4E02E2E5F7@PHSXMB24.partners.org>

A few other thoughts on the Nexus difference from a 6500 based on my experience
since I am still learning the 7K platform:


1) MPLS the 7K is VRF Light syle
2) Application of an access-list by doing a tftp->run (with out removing the acl
which is applied to the interface) is extremely taxing in the system and very
slow. The Nexus seems to recompile the ACL after each line there are work
arounds vs have the acl upload completely and recompile once.
3) Nexus STP is RSTP not pvst+
4) The TACACS implimentation of this platform seems incomplete. 
	TACACS is useable, but local-admin accounts must be configured and used
for configuration.
5) The layout of the configuration is different (as someone mentioned)
	Features must be enabled (ie., ospf,tacacs must be enabled by using
'feature ???') if ospf feature is not enabled, it can't be used until it's
enabled (not configured).
	OSPF is configured mostly under the interface (passive-interface,
process # vs globally)
	HSRP is configured like an interface where you enable the hsrp #, then
you are in a config-hsrp# mode where you then finish the hsrp config. HSRP is
not just configured under "router(conf-if)#"
6) QoS you specify the queueing structure (ie., 1P2q4T) and not the queueing or
scheduling or thresholds.  Obviously there is the ability to tweak the QoS, but
the base config viewing is much simpler
7) Obviously there are many hardware differences (Resilient Sups which are
better than the dual-sup on the 6500),  transfering the configuration from a
6500 to a 7K (ie., replacing a 6500 with a 7K) is pretty challenging. Think of
it from going from CatOS to CATIOS and having to create a script to migrate your
config (trunk, vrf) to the 7K.

Just some thoughts...

DMT
	
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Nick Hilliard
Sent: Wednesday, September 09, 2009 6:12 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Catalyst vs. Nexus

On 09/09/2009 09:08, Arie Vayner (avayner) wrote:
> There are a few differences between Catalyst switches and Nexus 
> switches.

The nexus n5k / n2k switches are a completely different architecture which use
different software.  I haven't played with them, but they show promise.

> Another major difference is the integration of Nexus 2000 Fabric 
> Extenders with Nexus 5000 switches. The Nexus 2000 switches basically 
> act as remote (over 10Gig fiber) "linecards" of the Nexus 5000. This 
> allows deploying top of the rack switches without the additional 
> management overhead:

The N2K only support 1000 connections, not 10/100.  So if you have slower speed
kit like console servers or tiny boxes or whatever, you will need to cope with
these separately.  This is noted obliquely in the documentation:

> http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps10110/dat
> a_sheet_c78-507093.html

> Layer 2 Features
[...]
> * Autonegotiation to 1000BASE-T; full duplex on host interfaces

Nick
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.


From nick at inex.ie  Wed Sep  9 07:18:26 2009
From: nick at inex.ie (Nick Hilliard)
Date: Wed, 09 Sep 2009 12:18:26 +0100
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <1F1F2AF9CD74144CAB1F5702D4F74A4E02E2E5F8@PHSXMB24.partners.org>
References: <1F1F2AF9CD74144CAB1F5702D4F74A4E02E2E5F8@PHSXMB24.partners.org>
Message-ID: <4AA78F02.3000402@inex.ie>

On 09/09/2009 11:58, Todd, Douglas M. wrote:
> So the 6500 is EARL7 and mpls runs in the ASIC, guess I don' understand the
> difference between the EARL7 and EARL8.   Thought mpls on the 6500 was also
> hardware is this why the 7K earl 8 does not completely support mpls like the
> 6500?

It's a software thing, I understand.  The N7K is pitched as a data centre 
switch rather than a WAN system, so maybe it makes some sense from the 
point of view of a product development manager not to implement full mpls 
for the time being.

 > Besided the idea of the 7K being a 6500 killer... :)

Well, sort of.  It's TCAM limited to 128k FIB entries which is very low, 
although I understand that it supports netflow properly, which is a real 
improvement.

> Why did they not make the 7K support pvst+ if the 5K supports it?

Heh, no idea :-)

Nick

From DTODD at PARTNERS.ORG  Wed Sep  9 06:58:05 2009
From: DTODD at PARTNERS.ORG (Todd, Douglas M.)
Date: Wed, 9 Sep 2009 06:58:05 -0400
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <4AA78887.3000804@inex.ie>
Message-ID: <1F1F2AF9CD74144CAB1F5702D4F74A4E02E2E5F8@PHSXMB24.partners.org>

Hey Nick:

So the 6500 is EARL7 and mpls runs in the ASIC, guess I don' understand the
difference between the EARL7 and EARL8.   Thought mpls on the 6500 was also
hardware is this why the 7K earl 8 does not completely support mpls like the
6500? Besided the idea of the 7K being a 6500 killer... :)

Why did they not make the 7K support pvst+ if the 5K supports it?  Guess moving
the RSPT is a better idea anyway.

Aggreed about the ospf interface style, make much more sense.  

DMT
-----Original Message-----
From: Nick Hilliard [mailto:nick at inex.ie] 
Sent: Wednesday, September 09, 2009 6:51 AM
To: Todd, Douglas M.
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Catalyst vs. Nexus

On 09/09/2009 11:43, Todd, Douglas M. wrote:
> 1) MPLS the 7K is VRF Light syle

it's EARL8, so it's mpls capable at a hardware level.

> 3) Nexus STP is RSTP not pvst+

The N5K supports pvst+:

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/data_sheet_c78
-461802.html

> 	OSPF is configured mostly under the interface (passive-interface, 
> process # vs globally)

That's a change for the better.  The IOS style ospfv2 configuration is all
wrong.

Nick


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.


From rdobbins at arbor.net  Wed Sep  9 08:10:57 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Wed, 9 Sep 2009 19:10:57 +0700
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <4AA78F02.3000402@inex.ie>
References: <1F1F2AF9CD74144CAB1F5702D4F74A4E02E2E5F8@PHSXMB24.partners.org>
	<4AA78F02.3000402@inex.ie>
Message-ID: <A10BE73A-B159-44EA-872D-5FC619EF3AC8@arbor.net>


On Sep 9, 2009, at 6:18 PM, Nick Hilliard wrote:

>  although I understand that it supports netflow properly, which is a  
> real improvement.


It does - packet-sampled control of flow creation (i.e., true sampled  
NetFlow), logical OR of TCP flags within a flow, dropped traffic,  
layer-2 NetFlow across ports within the same VLAN, larger NetFlow  
table size, etc.

ACL construction is much easier than on 6500 (doesn't have the weird  
LOU constraints), and you get per-interface uRPF mode settings, as  
well (vs. whole-box on 6500).

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

Sorry, sometimes I mistake your existential crises for technical
insights.

			-- xkcd #625


From rsm at fast-serv.com  Wed Sep  9 08:17:37 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Wed, 9 Sep 2009 08:17:37 -0400
Subject: [c-nsp] service-policy on virtual interface
In-Reply-To: <452396.77085.qm@web110108.mail.gq1.yahoo.com>
References: <20090908112733.M18911@fast-serv.com>
	<452396.77085.qm@web110108.mail.gq1.yahoo.com>
Message-ID: <20090909121511.M91209@fast-serv.com>

Thank Tony.  I knew I was going to have to dig into QoS further and you helped
me a lot.  My line cards are all 6724 units at the current time.

I have a spare 3750 laying around, assuming it has similar QoS features I'll
plug away at it for a bit with some load generators.

Cheers

--
Randy
www.FastServ.com

---------- Original Message -----------
From: Tony <td_miles at yahoo.com>
To: Randy McAnally <rsm at fast-serv.com>, Ian MacKinnon
<Ian.Mackinnon at lumison.net>, "cisco-nsp at puck.nether.net"
<cisco-nsp at puck.nether.net>
Sent: Tue, 8 Sep 2009 17:02:51 -0700 (PDT)
Subject: Re: [c-nsp] service-policy on virtual interface

> Hi Randy,
> 
> I remember the previous topic because I was the one who suggested 
> that you disable QOS globally (if you didn't need it) when you were 
> seeing throughput issues. I stand by this as the easiest solution at 
> the time, but now that you need to use QOS for something else, 
> you'll have to look at the queueing and work out what is happening 
> and how to fix it.
> 
> If you don't classify any of your traffic the it will all be in the 
> default class (ie. DSCP & COS = 0) and go into the queue for this class.
> 
> What happens depends on what hardware you have. As an example, if 
> you have a 6516-GE-TX card then the following happens you enable 
> QOS. If you run the command "show queueing int gigx/y" you will see 
> something like this:
> 
>   Default COS is 0
>     Queueing Mode In Tx direction: mode-cos
>     Transmit queues [type = 1p2q2t]:
>     Queue Id    Scheduling  Num of thresholds
>     -----------------------------------------
>        1         WRR low             2
>        2         WRR high            2
>        3         Priority            1
> 
>     WRR bandwidth ratios:  100[queue 1] 255[queue 2]
>     queue-limit ratios:     70[queue 1]  15[queue 2]  15[Pri 
> Queue]*same as Q2
> 
>     queue random-detect-min-thresholds
>     ----------------------------------
>       1    40[1] 70[2]
>       2    40[1] 70[2]
> 
>     queue random-detect-max-thresholds
>     ----------------------------------
>       1    70[1] 100[2]
>       2    70[1] 100[2]
> 
>     queue thresh cos-map
>     ---------------------------------------
>     1     1      0 1
>     1     2      2 3
>     2     1      4 6
>     2     2      7
>     3     1      5
> 
> From this we can see:
> 
> Number of queues = 3 (2 normal/configurable + 1 priority)
> Number of thresholds per queue = 2 thresholds (except PQ, which has 
> just 1)
> 
> You can see from the COS-MAP (or maybe you can't) that COS 0 & 1 are 
> assigned to queue 1, threshold 1. The real problem is the random-
> detect thresholds on the queue. What this means is that once the 
> queue gets full above the min-threshold the box will start random 
> throwing out packets (based on queue weightings and number of 
> packets in queues). When the queue gets above max-threshold then all 
> packets for this queue with the COS value will be dropped. This is 
> done to ensure there is some space in the queues for higher priority 
> packets.
> 
> From the card above you can see that unclassified traffic (COS 0)
>  will start getting discarded at 40% and as the queue gets fuller it 
> will progressively discard more. If the queue gets to 70% then ALL 
> COS0 traffic will be discarded. In queue 1 this 30% at the top of 
> the queue is for COS 2 & 3 packets in threshold 2.
> 
> This theoretically means that the maximum throughput you would see 
> on the above card with just enabling QOS and not configuring 
> anything is around 700Mbps (70% of 1Gbps). in reality it would 
> probably be a bit less, but that would be absolute maximum
> 
> You can change this behaviour with the commands:
> 
>  wrr-queue random-detect min-threshold
>  wrr-queue random-detect max-threshold
> 
> (you'll have to read the syntax for the commands, you need to put 
> queue and thresholds on them)
> 
> I'm using this card as an example because I have one in a box I can 
> play with, you'll need to adjust it for your particular situation. 
> All of the above is for TX queues, you may also have to adjust the 
> RX queues.
> 
> Now you can see why I previously said the easier option was just to 
> disable QOS ;)
> 
> regards,
> Tony.
> 
> --- On Tue, 8/9/09, Randy McAnally <rsm at fast-serv.com> wrote:
> 
> > From: Randy McAnally <rsm at fast-serv.com>
> > Subject: Re: [c-nsp] service-policy on virtual interface
> > To: "Randy McAnally" <rsm at fast-serv.com>, "Ian MacKinnon"
<Ian.Mackinnon at lumison.net>, "cisco-nsp at puck.nether.net"
<cisco-nsp at puck.nether.net>
> > Received: Tuesday, 8 September, 2009, 9:29 PM
> > Thanks, I don't want to enable global
> > QOS (queuing) which 'mls qos' will
> > enable.  The default queues cause all kinds of trouble
> > with our traffic (you
> > can see details in another topic I created couple months
> > back).
> > 
> > --
> > Randy
> > www.FastServ.com
> > 
> > ---------- Original Message -----------
> > From: "Randy McAnally" <rsm at fast-serv.com>
> > To: Ian MacKinnon <Ian.Mackinnon at lumison.net>,
> > "cisco-nsp at puck.nether.net"
> > <cisco-nsp at puck.nether.net>
> > Sent: Tue, 8 Sep 2009 07:13:24 -0400
> > Subject: Re: [c-nsp] service-policy on virtual interface
> > 
> > > By 'not classify' I meant all of our traffic is in the
> > same default 
> > > class. Could you verify that 'mls qos' is not needed
> > globally before 
> > > you can do 'mls qos vlan-based' on an interface?
> > > 
> > > Cheers
> > > 
> > > --
> > > Randy
> > > 
> > > ---------- Original Message -----------
> > > From: Ian MacKinnon <Ian.Mackinnon at lumison.net>
> > > To: Randy McAnally <rsm at fast-serv.com>,
> > "cisco-nsp at puck.nether.net"
> > > <cisco-nsp at puck.nether.net>
> > > Sent: Tue, 8 Sep 2009 16:05:57 +0100
> > > Subject: RE: [c-nsp] service-policy on virtual
> > interface
> > > 
> > > > Not seen problems turning on mls qos..
> > > > We have on the physicals :-
> > > > Int gi1/1
> > > > mls qos vlan-based
> > > > mls qos trust dscp
> > > > and a typical service policy looks like :-
> > > > policy-map 10MegPolice
> > > >   class class-default
> > > >    police 10000000 26000 32000 
> >   conform-action transmit 
> >    exceed-
> > > > action transmit 
> >    violate-action drop
> > > > 
> > > > what do you mean you don't classify?
> > > > 
> > > > Ian
> > > > 
> > > > -----Original Message-----
> > > > From: Randy McAnally [mailto:rsm at fast-serv.com]
> > > > Sent: 08 September 2009 11:54
> > > > To: Ian MacKinnon; cisco-nsp at puck.nether.net
> > > > Subject: RE: [c-nsp] service-policy on virtual
> > interface
> > > > 
> > > > 6500 platform.
> > > > 
> > > > Last time we had 'mls qos' enabled we had massive
> > speed/packet loss issues
> > > > with interfaces over 40% utilization since we
> > don't classify traffic.
> > > > 
> > > > Is there any possible issues you might see?
> > > > 
> > > > --
> > > > Randy
> > > > 
> > > > ---------- Original Message -----------
> > > > From: Ian MacKinnon <Ian.Mackinnon at lumison.net>
> > > > To: Randy McAnally <rsm at fast-serv.com>,
> > "cisco-nsp at puck.nether.net"
> > > > <cisco-nsp at puck.nether.net>
> > > > Sent: Tue, 8 Sep 2009 15:44:57 +0100
> > > > Subject: RE: [c-nsp] service-policy on virtual
> > interface
> > > > 
> > > > > Hi Randy,
> > > > > What platform?
> > > > > On 6500/7600 the answer is yes, you need mls
> > qos vlan-based on the
> > > > > physical interfaces and then you can police
> > on the SVI.
> > > > >
> > > > > Ian
> > > > >
> > > > > -----Original Message-----
> > > > > From: cisco-nsp-bounces at puck.nether.net
> > [mailto:cisco-nsp-
> > > > > bounces at puck.nether..net]
> > On Behalf Of Randy McAnally Sent: 08
> > > > > September 2009 11:40 To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp]
> > > > > service-policy on virtual interface
> > > > >
> > > > > Do the same commands work e.g.
> > 'service-policy input/output
> > > > > FooPolicy' at the virtual interface level
> > the same as they do on a
> > > > > physical port, both in and out?
> > > > >
> > > > > I'm trying to set up rate limiting 'further
> > up the line' rather than
> > > > > at the network edge, so we can pool customer
> > bandwidth and keep
> > > > > inbound floods of traffic from being passed
> > beyond the distribution layer.
> > > > >
> > > > > --
> > > > > Randy
> > > > >
> > _______________________________________________
> > > > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > > > https://puck..nether.net/mailman/listinfo/cisco-nsp
> > > > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > > >
> > > > > No virus found in this incoming message.
> > > > > Checked by AVG - www.avg.com
> > > > >
> > > > > Version: 8.5.409 / Virus Database:
> > 270.13.81/2350 - Release Date:
> > > > > 09/07/09 18:03:00
> > > > >
> > > > > --
> > > > >
> > > > > This email and any files transmitted with it
> > are confidential and intended
> > > > > solely for the use of the individual or
> > entity to whom they are addressed.
> > > > > If you have received this email in error
> > please notify the sender.
> > > > > Any offers or quotation of service are
> > subject to formal specification.
> > > > > Errors and omissions excepted.  Please
> > note that any views or
> > > > > opinions presented in this email are solely
> > those of the author and
> > > > > do not necessarily represent those of
> > Lumison. Finally, the
> > > > > recipient should check this email and any
> > attachments for the
> > > > > presence of viruses.  Lumison accept no
> > liability for any damage
> > > > > caused by any virus transmitted by this
> > email.
> > > > ------- End of Original Message -------
> 
>      
__________________________________________________________________________________
> Get more done like never before with Yahoo!7 Mail.
> Learn more: http://au.overview.mail.yahoo.com/
------- End of Original Message -------


From p.mayers at imperial.ac.uk  Wed Sep  9 08:25:40 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Wed, 09 Sep 2009 13:25:40 +0100
Subject: [c-nsp] service-policy on virtual interface
In-Reply-To: <20090909121511.M91209@fast-serv.com>
References: <20090908112733.M18911@fast-serv.com>	<452396.77085.qm@web110108.mail.gq1.yahoo.com>
	<20090909121511.M91209@fast-serv.com>
Message-ID: <4AA79EC4.7080903@imperial.ac.uk>

Randy McAnally wrote:
> Thank Tony.  I knew I was going to have to dig into QoS further and you helped
> me a lot.  My line cards are all 6724 units at the current time.
> 
> I have a spare 3750 laying around, assuming it has similar QoS features I'll

Very much not, IIRC.

From ltd at cisco.com  Wed Sep  9 08:51:29 2009
From: ltd at cisco.com (Lincoln Dale)
Date: Wed, 9 Sep 2009 22:51:29 +1000
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <1F1F2AF9CD74144CAB1F5702D4F74A4E02E2E5F7@PHSXMB24.partners.org>
References: <1F1F2AF9CD74144CAB1F5702D4F74A4E02E2E5F7@PHSXMB24.partners.org>
Message-ID: <739C2593-7972-443A-8F73-529CE6DF8761@cisco.com>

hi Todd,
a few of the cisco folks that are subscribed to cisco-nsp focus on the  
Nexus range & we're a pretty friendly bunch.
there's a few things below that aren't quite correct.  see inline  
below...

On 09/09/2009, at 8:43 PM, Todd, Douglas M. wrote:

> A few other thoughts on the Nexus difference from a 6500 based on my  
> experience
> since I am still learning the 7K platform:
>
> 1) MPLS the 7K is VRF Light syle

actually, at this point in time, MPLS is not available on N7K.  the  
current shipping M1 forwarding engine based I/O modules are capable of  
MPLS which will be enabled in a future release.

w.r.t. VRFs, everything on NX-OS is vrf aware. NX-OS is similar to IOS  
CLI in look-and-feel but one fundamental difference is that there is  
no 'global' routing table like there is in IOS.  everything is a vrf.

> 2) Application of an access-list by doing a tftp->run (with out  
> removing the acl
> which is applied to the interface) is extremely taxing in the system  
> and very
> slow. The Nexus seems to recompile the ACL after each line there are  
> work
> arounds vs have the acl upload completely and recompile once.

ACLs as entered in a "config terminal" session are applied to hardware  
the moment you hit enter on an individual line - yes.
the system is smart enough to do 'inline' ACL processing if you have  
an ACL that makes appropriate use of sequence numbers in it.

if you're just wholesale uploading a replacement ACL in bulk, then  
suggest you use "configure session" where you can ask the system to  
'verify' the ACL will fit in CL-TCAM resources then 'apply' it.
using configure sessions would not 'tax' it or iteratively recompute  
it on every new ACL line you enter.

see <http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_2/nx-os/system_management/configuration/guide/sm_7sessionmgr.html 
 >

ACLs are always committed in an atomic manner on N7K provided you have  
CL-TCAM resources to do so.

>
> 3) Nexus STP is RSTP not pvst+

N7Ks STP is PVRST(+) or MST - same as what you would have on a  
Catalyst platform.
the only thing that isn't there (intentionally) is the ability to  
configure N7K as a legacy 802.1D STP - although as dictated by the  
standards, N7K can talk legacy 802.1D to legacy bridges - but you  
cannot intentionally configure it to behave in that legacy manner.

this is actually a good thing. :)


> 4) The TACACS implimentation of this platform seems incomplete.
> 	TACACS is useable, but local-admin accounts must be configured and  
> used
> for configuration.

this isn't quite true.  RBAC (roles based access control) is applied  
to all management access, whether you're managing via CLI, SNMP or  
Netconf/XML.  this is a divergence from the historic IOS 'priv level  
15' / "enable" type mechanisms but there is no reason why you cannot  
assign a RBAC role from an AAA server whether that be via TACACS+ or  
RADIUS.

by default, a priv-level of 15 from an AAA server maps a user to the  
predefined RBAC role of network-admin or vdc-admin automatically.
alternatively you can have the AAA server provide the relevant AV-Pair  
to provide the RBAC role(s) a given user is in.

the documentation chapter on AAA on cisco.com provides the details for  
all of the above.
see <http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_2/nx-os/security/configuration/guide/Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_4.2_chapter3.html#con_1235748 
 >

>
> 5) The layout of the configuration is different (as someone mentioned)
> 	Features must be enabled (ie., ospf,tacacs must be enabled by using
> 'feature ???') if ospf feature is not enabled, it can't be used  
> until it's
> enabled (not configured).

yep - thats intentional.  services are 'conditional' on NX-OS.  until  
you enable the 'feature' the process for that feature is not running,  
consuming RAM or even part of the CLI parser chain.

> 	OSPF is configured mostly under the interface (passive-interface,
> process # vs globally)

there is the historic way of doing it too, if you wish to (e.g.  
'network' statements globally) - but the general feedback has been  
that interface-centric is more intuitive for many things.

> 6) QoS you specify the queueing structure (ie., 1P2q4T) and not the  
> queueing or
> scheduling or thresholds.  Obviously there is the ability to tweak  
> the QoS, but
> the base config viewing is much simpler

IOS is moving towards this level of QoS configuration too.  within  
Cisco parlence this is referred to as MQC (Modular QoS CLI).

>


cheers,

lincoln.

From td_miles at yahoo.com  Wed Sep  9 08:54:33 2009
From: td_miles at yahoo.com (Tony)
Date: Wed, 9 Sep 2009 05:54:33 -0700 (PDT)
Subject: [c-nsp] service-policy on virtual interface
In-Reply-To: <4AA79EC4.7080903@imperial.ac.uk>
Message-ID: <43068.26910.qm@web110103.mail.gq1.yahoo.com>



--- On Wed, 9/9/09, Phil Mayers <p.mayers at imperial.ac.uk> wrote:

> Randy McAnally wrote:
> > Thank Tony.? I knew I was going to have to dig
> into QoS further and you helped
> > me a lot.? My line cards are all 6724 units at
> the current time.
> > 
> > I have a spare 3750 laying around, assuming it has
> similar QoS features I'll
> 
> Very much not, IIRC.
> 

Yes, worlds apart. By all means have a go on your 3750 it can't hurt you any, but it won't be a direct translation from anything you get working on 3750 to 6500.

I'd recommend you have a look at Chapter 2 of the Cisco "Enterprise QoS Solution Reference Network Design Guide" (particularly the section on 6500 QoS, starts at 2-77):
http://www.cisco.com/univercd/cc/td/doc/solution/esm/qossrnd.pdf

Also have a read of the QoS section of 12.2SXH Software Configu Guide:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/qos.html

Both are very dry, but have a lot of information in them as well as some relevant examples.

Read, try and then ask more questions on the list if you get stuck !


regards,
Tony.


      __________________________________________________________________________________
Get more done like never before with Yahoo!7 Mail.
Learn more: http://au.overview.mail.yahoo.com/


From petelists at templin.org  Wed Sep  9 09:18:46 2009
From: petelists at templin.org (Pete Templin)
Date: Wed, 09 Sep 2009 08:18:46 -0500
Subject: [c-nsp] service-policy on virtual interface
In-Reply-To: <452396.77085.qm@web110108.mail.gq1.yahoo.com>
References: <452396.77085.qm@web110108.mail.gq1.yahoo.com>
Message-ID: <4AA7AB36.4060504@templin.org>

Tony wrote:

>> From the card above you can see that unclassified traffic (COS 0)
>> will start getting discarded at 40% and as the queue gets fuller it
>> will progressively discard more. If the queue gets to 70% then ALL
>> COS0 traffic will be discarded. In queue 1 this 30% at the top of
>> the queue is for COS 2 & 3 packets in threshold 2.
> 
> This theoretically means that the maximum throughput you would see on
> the above card with just enabling QOS and not configuring anything is
> around 700Mbps (70% of 1Gbps). in reality it would probably be a bit
> less, but that would be absolute maximum

Can you clarify this for me?  If 999Mbps of traffic is arriving on an 
'ingress' port and is the only traffic leaving on an 'egress' port, 
there shouldn't be much if any queueing, right?  Queueing should only be 
occurring when the (instantaneous) packet arrival rate exceeds the rate 
at which the device can dispatch the packets, and as those queues get to 
various thresholds of %-full, they'll execute WRR to manage the queue 
depth, correct?

pt

From david.freedman at uk.clara.net  Wed Sep  9 10:09:40 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Wed, 09 Sep 2009 15:09:40 +0100
Subject: [c-nsp] Tracking a dynamic default - supported?
Message-ID: <h88cv5$d6e$1@ger.gmane.org>

I can't find any information which would suggest that such a thing is an
unsupported configuration. Nonetheless, am unable to maintain a stable
track on a BGP default in 7200 12.2(33)SRC or 12.2(33)SRD (tested with
SRC2 and SRD2a)

#sh run | in track
track 20 ip route 0.0.0.0 0.0.0.0 reachability

#sh track 20
Track 20
  IP route 0.0.0.0 0.0.0.0 reachability
  Reachability is Down (BGP)
    5 changes, last change 4d14h
  First-hop interface is unknown

#sh ip ro 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 1234", distance 200, metric 0, candidate default path,
type internal
  Last update from 192.168.100.100 2d20h ago
  Routing Descriptor Blocks:
  * 192.168.100.100, from 192.168.100.100, 2d20h ago
      Route metric is 0, traffic share count is 1
      AS Hops 0

#sh ip ro 192.168.100.100
Routing entry for 192.168.100.100/32
  Known via "isis", distance 115, metric 300, type level-2
  Redistributing via isis
  Last update from 192.168.10.1 on FastEthernet0/0, 2d20h ago
  Routing Descriptor Blocks:
  * 192.168.10.1, from 192.168.100.100, via FastEthernet0/0
      Route metric is 300, traffic share count is 1

#sh ip cef 0.0.0.0 0.0.0.0 inte
0.0.0.0/0, epoch 0, RIB[B], refcount 5, per-destination sharing
  sources: RIB, DRH
  feature space:
   NetFlow: Origin AS 0, Peer AS 0, Mask Bits 0
   IPRM: 0x00018000
  ifnums:
   FastEthernet0/0(3): 192.168.10.1
  path 65FF4264, path list 65FEA258, share 1/1, type recursive, for
IPv4, flags eos indirection, neos indirection
  recursive via 192.168.100.100[IPv4:Default], fib 66033BB0, 1 terminal fib
    path 65FF38E0, path list 65FE9C1C, share 1/1, type attached nexthop,
for IPv4
      MPLS short path extensions: MOI flags = 0x0 label implicit-null
    nexthop 192.168.10.1 FastEthernet0/0, adjacency IP adj out of
FastEthernet0/0, addr 192.168.10.1 665F0B00
  output chain:
    loadinfo 65FD6C64, per-session, 1 choice, flags 0003, 164 locks
    flags: Per-session, for-rx-IPv4
    1 hash bucket
      < 0 > IP adj out of FastEthernet0/0, addr 192.168.10.1 665F0B00
    Subblocks:
     None


The track is down most of the time, but changes state to up randomly
when there is no change in the network and for short periods of time.

If you track another prefix with a mask longer than /0 with the same
nexthop, stays up continually.

When labbing, I can demonstrate the issue in 12.2(33)SR but not in , for
example 12.3(M) in which the track works but is labelled "unsupported"

#sh track
Track 20
  IP route 0.0.0.0 0.0.0.0 reachability
  Reachability is Up (unsupported)
    2 changes, last change 00:00:55
  First-hop interface is FastEthernet1/0


As usual, bugtool unhelpful.

Any ideas appreciated.



From cisco-nsp at slepicka.net  Wed Sep  9 10:33:23 2009
From: cisco-nsp at slepicka.net (James Slepicka)
Date: Wed, 09 Sep 2009 09:33:23 -0500
Subject: [c-nsp] Catalyst vs. Nexus
Message-ID: <4AA7BCB3.30307@slepicka.net>

 >>the 5010 will beat the 4900M in switching latency

Based on the numbers I have, there are some cases where the 4900M is a 
little faster.  It gets especially interesting when you toss 1Gb into 
the mix.  See http://slepicka.net/nexus5klatency.png.

I've deployed both -- 4900M in low-density 10Gb applications and Nexus 
5010/5020 in high-density 10Gb applications.  Other than some minor 
issues with the Nexus (off the top of my head, QoS support is limited -- 
probably due to the cut-through architecture -- and you can't connect a 
switch to a FEX port), I'm happy with them.

James


Darrin Machay wrote:
> Other than FCoE, the major difference is L3 switching. The 5010 is a
> Layer2-only device and the 4900M can do routing. If you're trying to
> shave off microseconds, the 5010 will beat the 4900M in switching
> latency. On the other hand, the 4900M is modular and well suited for
> mixed, low-density 1gig/10gig deployments.
>
>
> Darrin Machay
>
> YJT Solutions
> 440 South LaSalle St, Suite 3990
> Chicago, IL 60605
> Office: 312-362-4712
> Cell: 312-961-6977
> Darrin.Machay at YJTSolutions.com
> www.YJTSolutions.com 
>
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Michael Malitsky
> Sent: Tuesday, September 08, 2009 4:12 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Catalyst vs. Nexus
>
> Hello,
>
> I am working on the first 10Gig deployment in a small data center.  Main
> driver is a SQL database, so there will be a bunch of SQL servers
> virtualized using VMware, running against a SAN over iSCSI.
>
> I've done some research and it looks like I can build the network using
> a Catalyst 4900M or a Nexus 5010, at about the same cost.  I am familiar
> with the Catalyst family, but have no experience with the Nexus.  At
> this point, the only major difference I see is that Nexus supports Fibre
> Channel (which I don't need).  For being different product families, I
> am having a hard time understanding what the major differences are.  Can
> anyone enlighten me?  
> If anyone has hands-on experience with both and willing to share, that
> would be most appreciated.
>
> Thanks,
> Michael Malitsky
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   



From td_miles at yahoo.com  Wed Sep  9 10:29:51 2009
From: td_miles at yahoo.com (Tony)
Date: Wed, 9 Sep 2009 07:29:51 -0700 (PDT)
Subject: [c-nsp] service-policy on virtual interface
In-Reply-To: <4AA7AB36.4060504@templin.org>
Message-ID: <493845.312.qm@web110112.mail.gq1.yahoo.com>



--- On Wed, 9/9/09, Pete Templin <petelists at templin.org> wrote:


> Tony wrote:
> 
> >> From the card above you can see that unclassified
> traffic (COS 0)
> >> will start getting discarded at 40% and as the
> queue gets fuller it
> >> will progressively discard more. If the queue gets
> to 70% then ALL
> >> COS0 traffic will be discarded. In queue 1 this
> 30% at the top of
> >> the queue is for COS 2 & 3 packets in
> threshold 2.
> > 
> > This theoretically means that the maximum throughput
> you would see on
> > the above card with just enabling QOS and not
> configuring anything is
> > around 700Mbps (70% of 1Gbps). in reality it would
> probably be a bit
> > less, but that would be absolute maximum
> 
> Can you clarify this for me?? If 999Mbps of traffic is
> arriving on an 'ingress' port and is the only traffic
> leaving on an 'egress' port, there shouldn't be much if any
> queueing, right?? Queueing should only be occurring
> when the (instantaneous) packet arrival rate exceeds the
> rate at which the device can dispatch the packets, and as
> those queues get to various thresholds of %-full, they'll
> execute WRR to manage the queue depth, correct?
> 
> pt
>

I can see what you're getting at and it sounds correct.

It might hold true in a test environment where you only had two interfaces and you pushed traffic in one and out the other. If I had access to the gear to test this I would like to and see what happens with and without QoS enabled. In most normal environments you would probably have bursty traffic and over subscription somewhere even if it the egress interface wasn't being over-utilised (ie average egress <1000Mbps).


There are also buffer limits that are applied to the queues. The below is from the output of "show queueing int gigx/y":

    queue-limit ratios:     70[queue 1]  15[queue 2]  15[Pri Queue]

The above output says that queue 1 (ie. default class, COS 0) is only allowed 70% of the buffers. I'm not sure whether the "queue-limit" is a hard limit though (ie. it can't ever be exceeded). I'm not totally convinced of this part of my argument myself. It a 1:1 situation, do the queues fill at all or can the egress interface transmit as fast an ingress packets so that there is no queueing at all (as you questioned above) ?


You then have the ratio of how the queues are serviced, which is:

    WRR bandwidth ratios:  100[queue 1] 255[queue 2]

So queue 1 gets 100/(100+255) = 28% of the WRR scheduler and queue 2 gets 72%. Even though queue 2 is smaller, because it gets serviced with a higher weighting it will empty quicker than queue 1.

There is also the previous thread from the OP who stated that with default QoS enabled he was only getting ~400Mbps out of his Gbps port.

http://puck.nether.net/pipermail/cisco-nsp/2009-July/062100.html

This suggests that stuff is being dropped to make sure the queue buffers aren't filled so that there is room for any stuff with higher COS settings perhaps ? If the queue was filled with COS 0 traffic and some higher COS traffic comes along you would have to drop the higher COS traffic due to lack of space in buffers which kind of defeats the purpose of QoS (give/reserve priority to higher preferenced traffic). 

I would point to the below reference on not enabling QOS globally without looking at your traffic because you may get less performance than with QoS disabled:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/qos.html#wp1750716

This next link also has some examples of how changing some of the queue values affects what happens to the traffic in the queues.
http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a008015bf98.shtml


If someone else wants to correct me then please do. This is how I understand it works, but I'm happy for it to be otherwise. I'm aware that this stuff gets archived and people will be looking at it in the future, I don't want someting that is incorrect to be left around for people to be looking at thinking it is correct (peer reviewed == good).

Anyone more knowledgable on the subject wish to chime in ?


regards,
Tony.




      __________________________________________________________________________________
Get more done like never before with Yahoo!7 Mail.
Learn more: http://au.overview.mail.yahoo.com/


From peter at rathlev.dk  Wed Sep  9 11:00:20 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Wed, 09 Sep 2009 17:00:20 +0200
Subject: [c-nsp] service-policy on virtual interface
In-Reply-To: <4AA7AB36.4060504@templin.org>
References: <452396.77085.qm@web110108.mail.gq1.yahoo.com>
	<4AA7AB36.4060504@templin.org>
Message-ID: <1252508420.4394.6.camel@abehat.net.rm.dk>

On Wed, 2009-09-09 at 08:18 -0500, Pete Templin wrote:
> Tony wrote:
...
> >> will progressively discard more. If the queue gets to 70% then ALL
> >> COS0 traffic will be discarded. In queue 1 this 30% at the top of
> >> the queue is for COS 2 & 3 packets in threshold 2.
> > 
> > This theoretically means that the maximum throughput you would see
> > on the above card with just enabling QOS and not configuring
> > anything is around 700Mbps (70% of 1Gbps). in reality it would
> > probably be a bit less, but that would be absolute maximum
> 
> Can you clarify this for me?  If 999Mbps of traffic is arriving on an 
> 'ingress' port and is the only traffic leaving on an 'egress' port, 
> there shouldn't be much if any queueing, right?

Correct. The 70% WTD doesn't prevent the interface from carrying 1 Gbps.

> Queueing should only be occurring when the (instantaneous) packet
> arrival rate exceeds the rate at which the device can dispatch the
> packets, and as those queues get to various thresholds of %-full,
> they'll execute WRR to manage the queue depth, correct?

I think you mean RED instead of WRR, but yes.

This means that even an interface with no buffers could throw out full
line rate if the traffic arrives correctly.

It is of course still a problem to have a default WTD of 70% for
CoS/DSCP 0 traffic, which in OPs case is all traffic. The switch is
cannot handle bursts as well and you waste 30% of the expensive RAM used
for buffering.

Depending on burstiness of traffic this might or might not be a problem.
But for most practical purposes, enabling QoS and adjusting the first
WTD for the default queue (typically queue 1) up to 100% should give the
same results as no QoS.

-- 
Peter



From avayner at cisco.com  Wed Sep  9 11:09:15 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Wed, 9 Sep 2009 17:09:15 +0200
Subject: [c-nsp] Tracking a dynamic default - supported?
In-Reply-To: <h88cv5$d6e$1@ger.gmane.org>
References: <h88cv5$d6e$1@ger.gmane.org>
Message-ID: <FDD1CDB3FB499E4087CC7670BBCA22C63737D3@XMB-AMS-101.cisco.com>

David,

This is a known issue documented in (internal) CSCta08772 and
CSCsz48103.
Should be fixed in the next SRC (it is a recently fixed issue)

Thanks
Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman
Sent: Wednesday, September 09, 2009 17:10
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Tracking a dynamic default - supported?

I can't find any information which would suggest that such a thing is an
unsupported configuration. Nonetheless, am unable to maintain a stable
track on a BGP default in 7200 12.2(33)SRC or 12.2(33)SRD (tested with
SRC2 and SRD2a)

#sh run | in track
track 20 ip route 0.0.0.0 0.0.0.0 reachability

#sh track 20
Track 20
  IP route 0.0.0.0 0.0.0.0 reachability
  Reachability is Down (BGP)
    5 changes, last change 4d14h
  First-hop interface is unknown

#sh ip ro 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 1234", distance 200, metric 0, candidate default path,
type internal
  Last update from 192.168.100.100 2d20h ago
  Routing Descriptor Blocks:
  * 192.168.100.100, from 192.168.100.100, 2d20h ago
      Route metric is 0, traffic share count is 1
      AS Hops 0

#sh ip ro 192.168.100.100
Routing entry for 192.168.100.100/32
  Known via "isis", distance 115, metric 300, type level-2
  Redistributing via isis
  Last update from 192.168.10.1 on FastEthernet0/0, 2d20h ago
  Routing Descriptor Blocks:
  * 192.168.10.1, from 192.168.100.100, via FastEthernet0/0
      Route metric is 300, traffic share count is 1

#sh ip cef 0.0.0.0 0.0.0.0 inte
0.0.0.0/0, epoch 0, RIB[B], refcount 5, per-destination sharing
  sources: RIB, DRH
  feature space:
   NetFlow: Origin AS 0, Peer AS 0, Mask Bits 0
   IPRM: 0x00018000
  ifnums:
   FastEthernet0/0(3): 192.168.10.1
  path 65FF4264, path list 65FEA258, share 1/1, type recursive, for
IPv4, flags eos indirection, neos indirection
  recursive via 192.168.100.100[IPv4:Default], fib 66033BB0, 1 terminal
fib
    path 65FF38E0, path list 65FE9C1C, share 1/1, type attached nexthop,
for IPv4
      MPLS short path extensions: MOI flags = 0x0 label implicit-null
    nexthop 192.168.10.1 FastEthernet0/0, adjacency IP adj out of
FastEthernet0/0, addr 192.168.10.1 665F0B00
  output chain:
    loadinfo 65FD6C64, per-session, 1 choice, flags 0003, 164 locks
    flags: Per-session, for-rx-IPv4
    1 hash bucket
      < 0 > IP adj out of FastEthernet0/0, addr 192.168.10.1 665F0B00
    Subblocks:
     None


The track is down most of the time, but changes state to up randomly
when there is no change in the network and for short periods of time.

If you track another prefix with a mask longer than /0 with the same
nexthop, stays up continually.

When labbing, I can demonstrate the issue in 12.2(33)SR but not in , for
example 12.3(M) in which the track works but is labelled "unsupported"

#sh track
Track 20
  IP route 0.0.0.0 0.0.0.0 reachability
  Reachability is Up (unsupported)
    2 changes, last change 00:00:55
  First-hop interface is FastEthernet1/0


As usual, bugtool unhelpful.

Any ideas appreciated.


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From jabley at hopcount.ca  Wed Sep  9 11:50:07 2009
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 9 Sep 2009 11:50:07 -0400
Subject: [c-nsp] small cisco as ethernet bridge, IPv6 broken, sadness
In-Reply-To: <17838240D9A5544AAA5FF95F8D52031606AFC377@ad-exh01.adhost.lan>
References: <CBABDD85-7831-45A1-8F80-09BF5DFAEDCA@hopcount.ca>
	<17838240D9A5544AAA5FF95F8D52031606AFC377@ad-exh01.adhost.lan>
Message-ID: <287D523C-731C-4108-9644-55B75C434F6F@hopcount.ca>


On 2009-09-08, at 18:47, Michael K. Smith - Adhost wrote:

> I don't think the bridge is really transparent due to the 'bridge 1
> route ip' on your exchange-point side device.  If possible, you might
> want to try removing that statement (if you're local to the device, of
> course) to see if that does it.  I don't think there is a 'bridge 1
> route ipv6'.

I did try removing that, and managing that bridge through the console,  
but I still couldn't pass IPv6 frames.


From jabley at hopcount.ca  Wed Sep  9 11:50:47 2009
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 9 Sep 2009 11:50:47 -0400
Subject: [c-nsp] small cisco as ethernet bridge, IPv6 broken, sadness
In-Reply-To: <FDD1CDB3FB499E4087CC7670BBCA22C63734E2@XMB-AMS-101.cisco.com>
References: <CBABDD85-7831-45A1-8F80-09BF5DFAEDCA@hopcount.ca>
	<FDD1CDB3FB499E4087CC7670BBCA22C63734E2@XMB-AMS-101.cisco.com>
Message-ID: <0B76186D-D295-4CF3-BC14-486E11EE58DA@hopcount.ca>


On 2009-09-09, at 04:13, Arie Vayner (avayner) wrote:

> Did you check for MTU issues?
> IPv6 has different MTU requirements than IPv4, and the setup you are
> describing is prone to MTU issues due to the reduced MTU on the L2
> transport.

That's an interesting idea, but in this case I've tested and the  
layer-2 transport is 1500-byte clean, which matches the interface MTUs  
everywhere.


Joe

From jabley at hopcount.ca  Wed Sep  9 11:53:55 2009
From: jabley at hopcount.ca (Joe Abley)
Date: Wed, 9 Sep 2009 11:53:55 -0400
Subject: [c-nsp] small cisco as ethernet bridge, IPv6 broken, sadness
In-Reply-To: <87tyzcwl6j.fsf@nemi.mork.no>
References: <CBABDD85-7831-45A1-8F80-09BF5DFAEDCA@hopcount.ca>
	<87tyzcwl6j.fsf@nemi.mork.no>
Message-ID: <6EEF6BC6-3213-4FDE-9AD4-F4A0B7071898@hopcount.ca>


On 2009-09-09, at 04:56, Bj?rn Mork wrote:

> Joe Abley <jabley at hopcount.ca> writes:
>
>> interface FastEthernet0/1
>> description facing the exchange point
>> bridge-group 1
>> bridge-group 1 output-pattern-list 1100
>
> And this access list does allow e.g. IPv6 multicast frames?

That access list is just cleaning frames being sent to the exchange to  
make sure that weird crap doesn't leak over there. The exchange point  
in question only permits one nominated MAC per port, and will shut  
down the port automagically if it hears more.

access-list 1100 permit 0023.9c72.d700 0000.0000.0000 0000.0000.0000  
ffff.ffff.ffff

That's the complete list, as configured.


From asturluismi at gmail.com  Wed Sep  9 13:34:24 2009
From: asturluismi at gmail.com (luismi)
Date: Wed, 09 Sep 2009 19:34:24 +0200
Subject: [c-nsp] PBR, order of operations for "set" directives ?
Message-ID: <1252517664.7630.4.camel@dsba-ipso>

Hi all,

We have an small issue here and we have over the table some workarounds
and one them is related with the order of operations of the "set"
directives under a route-map used for policy routing.

In fact we would like to apply a code like this:

route-map selectvrf permit 10
 match ip address foo
 set ip next-hop verify-availability 10.53.0.37 1 track 10
 set vrf vrf_backup4foo

We know that we could use "set ip next-hop verify-availability" and then
"set ip next-hop" but we can't do that because under vrf vrf_backup4foo
there is another 10.53.0.37.
And we have some redistribution between VRFs and BGP... So it is not
possible.

So, the question is... 
Is there anyone here with information about the order of operations of
the "set" directives under a route-map used for policy routing?

Regards.


From amsoares at netcabo.pt  Wed Sep  9 13:52:04 2009
From: amsoares at netcabo.pt (Antonio Soares)
Date: Wed, 9 Sep 2009 18:52:04 +0100
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <200909081035.tcp24@psirt.cisco.com>
References: <200909081035.tcp24@psirt.cisco.com>
Message-ID: <052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>

Hello group,

What actions are you taking ? What is the real risk ?

http://www.cisco.com/warp/public/707/cisco-sa-20090908-tcp24.shtml



Thanks.

Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt



From tdurack at gmail.com  Wed Sep  9 13:58:48 2009
From: tdurack at gmail.com (Tim Durack)
Date: Wed, 9 Sep 2009 13:58:48 -0400
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <739C2593-7972-443A-8F73-529CE6DF8761@cisco.com>
References: <1F1F2AF9CD74144CAB1F5702D4F74A4E02E2E5F7@PHSXMB24.partners.org>
	<739C2593-7972-443A-8F73-529CE6DF8761@cisco.com>
Message-ID: <9e246b4d0909091058nb61bd7bjbaa1d32679db4d8@mail.gmail.com>

>
> actually, at this point in time, MPLS is not available on N7K.  the current
> shipping M1 forwarding engine based I/O modules are capable of MPLS which
> will be enabled in a future release.
>

Interesting. I guess the N7K might yet replace the C6K. If Cisco would ship
an EARL8 based Sup for the 6500 running NX-OS, I'd be happy...

Question about the N7K: are VLANs global to the switch, like the C6K, or can
they be configured to be local to a switchport? I'd like to know if L3
switchports can have the same subinterfaces or not.

Tim:>

From tstevens at cisco.com  Wed Sep  9 14:19:08 2009
From: tstevens at cisco.com (Tim Stevenson)
Date: Wed, 09 Sep 2009 11:19:08 -0700
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <9e246b4d0909091058nb61bd7bjbaa1d32679db4d8@mail.gmail.com>
References: <1F1F2AF9CD74144CAB1F5702D4F74A4E02E2E5F7@PHSXMB24.partners.org>
	<739C2593-7972-443A-8F73-529CE6DF8761@cisco.com>
	<9e246b4d0909091058nb61bd7bjbaa1d32679db4d8@mail.gmail.com>
Message-ID: <200909091819.n89IJJIA025627@sj-core-2.cisco.com>

Hi Tim, please see inline below:

At 10:58 AM 9/9/2009, Tim Durack gushed:

> >
> > actually, at this point in time, MPLS is not available on N7K.  the current
> > shipping M1 forwarding engine based I/O modules are capable of MPLS which
> > will be enabled in a future release.
> >
>
>Interesting. I guess the N7K might yet replace the C6K. If Cisco would ship
>an EARL8 based Sup for the 6500 running NX-OS, I'd be happy...

There is a longterm roadmap on 6k for an E8 based sup, but that would 
be an IOS system.


>Question about the N7K: are VLANs global to the switch,

No, they are interface local.

>  like the C6K, or can
>they be configured to be local to a switchport? I'd like to know if L3
>switchports can have the same subinterfaces or not.

You can have an arbitrary # of subinterfaces terminating the same 
vlan ID, along with an SVI & switchports with that same VLAN ID, and 
route between them all.


Hope that helps,
Tim


>Tim:>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
><https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at 
><http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.


From gert at greenie.muc.de  Wed Sep  9 16:38:21 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 9 Sep 2009 22:38:21 +0200
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
Message-ID: <20090909203821.GC117@greenie.muc.de>

Hi,

On Wed, Sep 09, 2009 at 06:52:04PM +0100, Antonio Soares wrote:
> What actions are you taking ? What is the real risk ?
> 
> http://www.cisco.com/warp/public/707/cisco-sa-20090908-tcp24.shtml

"scream, wave your arms, run around in circles"...

Seriously: I'm not exactly sure what the actual impact is.

What we're going to do is:

 - identify what parts of IOS use TCP (telnet, ssh, rsh, bgp, ldp, 
   http/s, ftp, others?)

   (for some weird reason, "show ip sockets" only shows UDP sockets on
   our boxes, and "show tcp brief" only shows ESTABLISHED TCP sessions
   - how can I see what TCP LISTEN sockets are there??)


 - find out what the impact is on each ("fill all available slots, lock
   out legitimate admins" or "fill all available memory, killing the box")

 - find out how to mitigate
    - telnet/ssh -> vty ACLs
    - rsh -> recent IOSes send RST to unknown peers
    - bgp -> takes care of itself (doesn't talk to unknown peers)
    - http/https -> turn off
    - ldp -> ??
    - ftp -> ??
    - generic -> receive ACLs ("if the platform happens to support it"),
                 infrastructure ACLs ("not always effective in catching
                 all possible IP addresses that a box with many customer
                 /30 or /29s might have")

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090909/2fb57fcd/attachment.bin>

From justin at justinshore.com  Wed Sep  9 17:21:50 2009
From: justin at justinshore.com (Justin Shore)
Date: Wed, 09 Sep 2009 16:21:50 -0500
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
 ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
Message-ID: <4AA81C6E.9060401@justinshore.com>

Antonio Soares wrote:
> Hello group,
> 
> What actions are you taking ? What is the real risk ?
> 
> http://www.cisco.com/warp/public/707/cisco-sa-20090908-tcp24.shtml

If I'm reading the notes correctly, to exploit the problem the attacker 
must be able to complete a TCP 3-way handshake.  That would imply that 
the attackers packets can either get through iACLs or that there are no 
ACLs in place.  This will mainly affect those people with unsecured 
TCP-based services such as telnet, SSH, RSH, SCP, HTTP, and HTTPS. 
Routers providing WebVPN services are at risk and need to be upgraded to 
fix the problem since disabling WebVPN is probably not an option.  Other 
TCP services like BGP and LDP shouldn't be affected unless one of your 
configured neighbors is going to exploit the vulnerability.  If you 
can't trust your own equipment or your peers to not exploit 
vulnerabilities on your equipment....

So the hundreds of thousands of "under-managed" IOS devices out there 
that have the default config with TCP services like HTTP and telnet 
enabled are going to suffer.  All the more reason for Cisco to change 
the default configuration to default to having all services disabled out 
of the box.  Make the admin turn on features themselves that compromise 
their security.  No reason to compromise their security for them.

Fixing this would require implementing security basics such as creating 
a VTY ACL, creating a HTTP/HTTPS ACL or disabling it altogether if it's 
not used, implementing CoPP, iACLs, etc.  Usual stuff.

It looks like I'll be doing a round of upgrades in November.  It's time 
anyway.

Justin

From bitkraft at gmail.com  Wed Sep  9 17:58:53 2009
From: bitkraft at gmail.com (Brian Spade)
Date: Wed, 9 Sep 2009 14:58:53 -0700
Subject: [c-nsp] Syslog Solutions
In-Reply-To: <505b616c0909041626v5d40e10ds779863f1a3fbefee@mail.gmail.com>
References: <505b616c0909041626v5d40e10ds779863f1a3fbefee@mail.gmail.com>
Message-ID: <505b616c0909091458n2fc451ccy4e111c1675c40838@mail.gmail.com>

Hi,

I have received some helpful responses privately and will summarize to share
with cisco-nsp in a few days.

/bs

On Fri, Sep 4, 2009 at 4:26 PM, Brian Spade <bitkraft at gmail.com> wrote:

> Hi,
>
> Can people recommend a useful solution for syslog, SNMP traps and event
> correlation?  I'm not even sure where to start.  I know about syslog-ng but
> am looking for a syslog/snmp trap collector with future capabilities of
> event correlation.  The event correlation would be able to accept any data
> source / device via SNMP or syslog.
>
> Commercial or open-source is fine with the latter being more preferrable.
>
> Thanks!
> /bs
>

From mtinka at globaltransit.net  Wed Sep  9 22:41:59 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Thu, 10 Sep 2009 10:41:59 +0800
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <4AA78887.3000804@inex.ie>
References: <1F1F2AF9CD74144CAB1F5702D4F74A4E02E2E5F7@PHSXMB24.partners.org>
	<4AA78887.3000804@inex.ie>
Message-ID: <200909101042.04053.mtinka@globaltransit.net>

On Wednesday 09 September 2009 06:50:47 pm Nick Hilliard 
wrote:

> That's a change for the better.  The IOS style ospfv2
> configuration is all wrong.

IOS has had OSPF configuration just like IS-IS (i.e., under 
the interface), for quite a while now:

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/ospfarea.html

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090910/872bdd8c/attachment.bin>

From olof.kasselstrand at gmail.com  Thu Sep 10 06:03:02 2009
From: olof.kasselstrand at gmail.com (Olof Kasselstrand)
Date: Thu, 10 Sep 2009 12:03:02 +0200
Subject: [c-nsp] small cisco as ethernet bridge, IPv6 broken, sadness
In-Reply-To: <6EEF6BC6-3213-4FDE-9AD4-F4A0B7071898@hopcount.ca>
References: <CBABDD85-7831-45A1-8F80-09BF5DFAEDCA@hopcount.ca>
	<87tyzcwl6j.fsf@nemi.mork.no>
	<6EEF6BC6-3213-4FDE-9AD4-F4A0B7071898@hopcount.ca>
Message-ID: <e7dbea8e0909100303l66ee70a1gd2d6f55c9802b6a7@mail.gmail.com>

I think there is some serious problems with BVIs and IPv6.

// Olof



On Wed, Sep 9, 2009 at 5:53 PM, Joe Abley <jabley at hopcount.ca> wrote:
>
> On 2009-09-09, at 04:56, Bj?rn Mork wrote:
>
>> Joe Abley <jabley at hopcount.ca> writes:
>>
>>> interface FastEthernet0/1
>>> description facing the exchange point
>>> bridge-group 1
>>> bridge-group 1 output-pattern-list 1100
>>
>> And this access list does allow e.g. IPv6 multicast frames?
>
> That access list is just cleaning frames being sent to the exchange to make
> sure that weird crap doesn't leak over there. The exchange point in question
> only permits one nominated MAC per port, and will shut down the port
> automagically if it hears more.
>
> access-list 1100 permit 0023.9c72.d700 0000.0000.0000 0000.0000.0000
> ffff.ffff.ffff
>
> That's the complete list, as configured.
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From vikassharmas at gmail.com  Thu Sep 10 06:38:49 2009
From: vikassharmas at gmail.com (Vikas Sharma)
Date: Thu, 10 Sep 2009 16:08:49 +0530
Subject: [c-nsp] 3750 - power AC / DC
Message-ID: <cca140000909100338g5de3f97bj3e1eddc18322d95c@mail.gmail.com>

Hi,

Is there any command on 3750 (e and non-E) switches which can tell
whether the power is AC or DC in the box? Like in 7206 we have sh
environemnt..

Regards,

From avayner at cisco.com  Thu Sep 10 06:40:56 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Thu, 10 Sep 2009 12:40:56 +0200
Subject: [c-nsp] small cisco as ethernet bridge, IPv6 broken, sadness
In-Reply-To: <e7dbea8e0909100303l66ee70a1gd2d6f55c9802b6a7@mail.gmail.com>
References: <CBABDD85-7831-45A1-8F80-09BF5DFAEDCA@hopcount.ca><87tyzcwl6j.fsf@nemi.mork.no><6EEF6BC6-3213-4FDE-9AD4-F4A0B7071898@hopcount.ca>
	<e7dbea8e0909100303l66ee70a1gd2d6f55c9802b6a7@mail.gmail.com>
Message-ID: <FDD1CDB3FB499E4087CC7670BBCA22C63CF177@XMB-AMS-101.cisco.com>

Olof,

You are right. I just did a more thorough investigation, and it seems that IPv6 has not been supported on BVI up till (very) recently.

There is an enhancement which is implemented through CSCta27529 "IPv6 support for BVI interface". It is a new fix, and it should be integrated in the coming 12.4T releases.
I am checking with the DE to see in which release we should officially expect it, and would update.

Thanks
Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Olof Kasselstrand
Sent: Thursday, September 10, 2009 13:03
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] small cisco as ethernet bridge, IPv6 broken, sadness

I think there is some serious problems with BVIs and IPv6.

// Olof



On Wed, Sep 9, 2009 at 5:53 PM, Joe Abley <jabley at hopcount.ca> wrote:
>
> On 2009-09-09, at 04:56, Bj?rn Mork wrote:
>
>> Joe Abley <jabley at hopcount.ca> writes:
>>
>>> interface FastEthernet0/1
>>> description facing the exchange point
>>> bridge-group 1
>>> bridge-group 1 output-pattern-list 1100
>>
>> And this access list does allow e.g. IPv6 multicast frames?
>
> That access list is just cleaning frames being sent to the exchange to make
> sure that weird crap doesn't leak over there. The exchange point in question
> only permits one nominated MAC per port, and will shut down the port
> automagically if it hears more.
>
> access-list 1100 permit 0023.9c72.d700 0000.0000.0000 0000.0000.0000
> ffff.ffff.ffff
>
> That's the complete list, as configured.
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From olof.kasselstrand at gmail.com  Thu Sep 10 06:50:17 2009
From: olof.kasselstrand at gmail.com (Olof Kasselstrand)
Date: Thu, 10 Sep 2009 12:50:17 +0200
Subject: [c-nsp] small cisco as ethernet bridge, IPv6 broken, sadness
In-Reply-To: <FDD1CDB3FB499E4087CC7670BBCA22C63CF177@XMB-AMS-101.cisco.com>
References: <CBABDD85-7831-45A1-8F80-09BF5DFAEDCA@hopcount.ca>
	<87tyzcwl6j.fsf@nemi.mork.no>
	<6EEF6BC6-3213-4FDE-9AD4-F4A0B7071898@hopcount.ca>
	<e7dbea8e0909100303l66ee70a1gd2d6f55c9802b6a7@mail.gmail.com>
	<FDD1CDB3FB499E4087CC7670BBCA22C63CF177@XMB-AMS-101.cisco.com>
Message-ID: <e7dbea8e0909100350j5f02f9c8sf9f6f043e73a750d@mail.gmail.com>

Just as I thought then =)

Looking forward to the 12.4T!

// Olof


On Thu, Sep 10, 2009 at 12:40 PM, Arie Vayner (avayner)
<avayner at cisco.com> wrote:
> Olof,
>
> You are right. I just did a more thorough investigation, and it seems that IPv6 has not been supported on BVI up till (very) recently.
>
> There is an enhancement which is implemented through CSCta27529 "IPv6 support for BVI interface". It is a new fix, and it should be integrated in the coming 12.4T releases.
> I am checking with the DE to see in which release we should officially expect it, and would update.
>
> Thanks
> Arie
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Olof Kasselstrand
> Sent: Thursday, September 10, 2009 13:03
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] small cisco as ethernet bridge, IPv6 broken, sadness
>
> I think there is some serious problems with BVIs and IPv6.
>
> // Olof
>
>
>
> On Wed, Sep 9, 2009 at 5:53 PM, Joe Abley <jabley at hopcount.ca> wrote:
>>
>> On 2009-09-09, at 04:56, Bj?rn Mork wrote:
>>
>>> Joe Abley <jabley at hopcount.ca> writes:
>>>
>>>> interface FastEthernet0/1
>>>> description facing the exchange point
>>>> bridge-group 1
>>>> bridge-group 1 output-pattern-list 1100
>>>
>>> And this access list does allow e.g. IPv6 multicast frames?
>>
>> That access list is just cleaning frames being sent to the exchange to make
>> sure that weird crap doesn't leak over there. The exchange point in question
>> only permits one nominated MAC per port, and will shut down the port
>> automagically if it hears more.
>>
>> access-list 1100 permit 0023.9c72.d700 0000.0000.0000 0000.0000.0000
>> ffff.ffff.ffff
>>
>> That's the complete list, as configured.
>>
>> _______________________________________________
>> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From skoal at skoal.name  Thu Sep 10 06:47:11 2009
From: skoal at skoal.name (Gergely Antal)
Date: Thu, 10 Sep 2009 12:47:11 +0200
Subject: [c-nsp] 3750 - power AC / DC
In-Reply-To: <cca140000909100338g5de3f97bj3e1eddc18322d95c@mail.gmail.com>
References: <cca140000909100338g5de3f97bj3e1eddc18322d95c@mail.gmail.com>
Message-ID: <4AA8D92F.1050800@skoal.name>

sh inventory raw...

like:

NAME: "Switch 1 - Power Supply", DESCR: "FRU Power Supply"
PID: C3K-PWR-265WAC    , VID: V01, SN:


Vikas Sharma wrote:
> Hi,
> 
> Is there any command on 3750 (e and non-E) switches which can tell
> whether the power is AC or DC in the box? Like in 7206 we have sh
> environemnt..
> 
> Regards,
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090910/8a2587c1/attachment.bin>

From gert at greenie.muc.de  Thu Sep 10 08:16:17 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Thu, 10 Sep 2009 14:16:17 +0200
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <4AA8E79E.2030109@sara.nl>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
Message-ID: <20090910121617.GH1508@greenie.muc.de>

Hi,

On Thu, Sep 10, 2009 at 01:48:46PM +0200, Mark Meijerink wrote:
> When your run the show tcp brief all command you also see the listening ports.
> 
> router#show tcp brief ?
>   all  All end-points (even listeners)

Oh.  Cool.  For whatever reason, I overlooked this.

But anyway - my routers are lying to me.  They list *.179 just fine (BGP),
but all the other interesting stuff (telnet, ssh, ldp) is not there...

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de

From elparis at cisco.com  Thu Sep 10 09:22:04 2009
From: elparis at cisco.com (Eloy Paris)
Date: Thu, 10 Sep 2009 09:22:04 -0400
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation
	Denial	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <20090910121617.GH1508@greenie.muc.de>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
Message-ID: <20090910132204.GA14501@turbo.cisco.com>

Hi Gert,

On Thu, Sep 10, 2009 at 02:16:17PM +0200, Gert Doering wrote:

> Hi,
> 
> On Thu, Sep 10, 2009 at 01:48:46PM +0200, Mark Meijerink wrote:
> > When your run the show tcp brief all command you also see the listening ports.
> > 
> > router#show tcp brief ?
> >   all  All end-points (even listeners)
> 
> Oh.  Cool.  For whatever reason, I overlooked this.
> 
> But anyway - my routers are lying to me.  They list *.179 just fine (BGP),
> but all the other interesting stuff (telnet, ssh, ldp) is not there...

In a Cisco Security Advisory that we published last year
(http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml), we
wrote the following:

'Different versions of Cisco IOS have different ways of verifying
whether the Cisco IOS device is listening for SIP messages. The "show ip
sockets", "show udp", "show tcp brief all", and "show control-plane host
open-ports" commands can be used to determine this, although not all of
these commands work on all IOS releases. Since it is not practical in
this document to provide a list of commands corresponding to the various
releases, users should try the aforementioned commands to determine
which ones work for their device.'

The problem is that historically we've had different internal APIs
that applications and services can use to register the ports they need
to open. I believe "show control-plane host open-ports" is the latest
incarnation and the desired way moving forward but not all applications
and services have migrated to it which is why we still rely on different
commands.

Cheers,

-- 

Eloy Paris
Cisco PSIRT

From gert at greenie.muc.de  Thu Sep 10 09:23:52 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Thu, 10 Sep 2009 15:23:52 +0200
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <4AA8FA97.7070906@sara.nl>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de> <4AA8FA97.7070906@sara.nl>
Message-ID: <20090910132352.GI1508@greenie.muc.de>

Hi,

On Thu, Sep 10, 2009 at 03:09:43PM +0200, Mark Meijerink wrote:
> When I run the command I see al the active BGP/SSH/LDP sessions with Local Address, Foreign Address and state (ESTAB/LISTEN)

Which IOS version is that?  I tried with 12.2S and 12.2SXF and SXI2,
and while I see telnet/LDP as "ESTAB", there's no "LISTEN" for either.

Besides the output format being horribly broken... any way to turn off
the DNS resolution and long-name-mangling here?  A very nice specimen
is this one...:

52CDE4A4  C                           2620:0:6B0::26E5:4242.       ESTAB
          isco-z-XYZ-GRH-Peer.Space.Ne36163                                    

"I have a slight idea what this might be, but it's a bit hard to see"


> There is one entry in the table which I find a bit strange.
> ######## *.*                     *.*                    LISTEN
> 
> Listener on all ports???

Makes the "what ports do I need to check" assessment a bit tricky 
indeed...

I can see this one ("*") on SXH3a and 12.2S, but not on SXI2...

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090910/ec3664b6/attachment.bin>

From gert at greenie.muc.de  Thu Sep 10 09:32:33 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Thu, 10 Sep 2009 15:32:33 +0200
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <20090910132204.GA14501@turbo.cisco.com>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
	<20090910132204.GA14501@turbo.cisco.com>
Message-ID: <20090910133233.GJ1508@greenie.muc.de>

Hi,

On Thu, Sep 10, 2009 at 09:22:04AM -0400, Eloy Paris wrote:
> > But anyway - my routers are lying to me.  They list *.179 just fine (BGP),
> > but all the other interesting stuff (telnet, ssh, ldp) is not there...
> 
> In a Cisco Security Advisory that we published last year
> (http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml), we
> wrote the following:
[..]
> The problem is that historically we've had different internal APIs
> that applications and services can use to register the ports they need
> to open. I believe "show control-plane host open-ports" is the latest
> incarnation and the desired way moving forward but not all applications
> and services have migrated to it which is why we still rely on different
> commands.

Thanks for that insight.  It doesn't *really* enlighten me, unfortunately.

The "show control-plane host open-ports" command is not available on
12.2S, 12.3 main, 12.4 main or 12.2SXF/SXH/SXI up to SXI2.  

None of the other commands reliably display *TCP* listening sockets.

So - to summarize this: "the only way to reliably detect what sockets
the box is listening on is to run nmap against it", right?

<rant>
This is really embarrassing, for a product shipping in this century...

(and I can't really see why "how is the service registering for a given
TCP port internally" should have any effect on "display ports registered
for services", people are known to have written programs that query 
multiple data sources and present the result in a concise format...)
</rant>

*sigh*

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090910/a9d13c42/attachment-0001.bin>

From elparis at cisco.com  Thu Sep 10 09:49:36 2009
From: elparis at cisco.com (Eloy Paris)
Date: Thu, 10 Sep 2009 09:49:36 -0400
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation
	Denial	of Service Vulnerabilities in Multiple Cisco Products
In-Reply-To: <20090910133233.GJ1508@greenie.muc.de>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
	<20090910132204.GA14501@turbo.cisco.com>
	<20090910133233.GJ1508@greenie.muc.de>
Message-ID: <20090910134936.GG17992@cisco.com>

Hi Gert,

On Thu, Sep 10, 2009 at 03:32:33PM +0200, Gert Doering wrote:

> On Thu, Sep 10, 2009 at 09:22:04AM -0400, Eloy Paris wrote:
> > > But anyway - my routers are lying to me.  They list *.179 just fine (BGP),
> > > but all the other interesting stuff (telnet, ssh, ldp) is not there...
> > 
> > In a Cisco Security Advisory that we published last year
> > (http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml), we
> > wrote the following:
> [..]
> > The problem is that historically we've had different internal APIs
> > that applications and services can use to register the ports they need
> > to open. I believe "show control-plane host open-ports" is the latest
> > incarnation and the desired way moving forward but not all applications
> > and services have migrated to it which is why we still rely on different
> > commands.
> 
> Thanks for that insight.  It doesn't *really* enlighten me, unfortunately.
> 
> The "show control-plane host open-ports" command is not available on
> 12.2S, 12.3 main, 12.4 main or 12.2SXF/SXH/SXI up to SXI2.  
> 
> None of the other commands reliably display *TCP* listening sockets.
> 
> So - to summarize this: "the only way to reliably detect what sockets
> the box is listening on is to run nmap against it", right?

Unfortunately, yes.

> <rant>
> This is really embarrassing, for a product shipping in this century...

No disagreement here. For one, this state of affairs puts us (the Cisco
PSIRT) in a difficult situation when we write our Security Advisories
since we don't have a simple, single way to tell our customers how to
check if their devices are affected by whatever vulnerability we are
disclosing.

> 
> (and I can't really see why "how is the service registering for a given
> TCP port internally" should have any effect on "display ports registered
> for services", people are known to have written programs that query 
> multiple data sources and present the result in a concise format...)

I am not privy to the details but I think it's been a matter of
re-writing the existing show commands to use data from multiple data
sources, or moving everybody to a single API and use a single source; it
seems like the latter is what has been chosen.

Cheers,

-- 

Eloy Paris
Cisco PSIRT

From rsm at fast-serv.com  Thu Sep 10 09:50:23 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Thu, 10 Sep 2009 09:50:23 -0400
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <20090910133233.GJ1508@greenie.muc.de>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
	<20090910132204.GA14501@turbo.cisco.com>
	<20090910133233.GJ1508@greenie.muc.de>
Message-ID: <20090910134905.M17612@fast-serv.com>

> So - to summarize this: "the only way to reliably detect what sockets
> the box is listening on is to run nmap against it", right?

Regardless, run NMAP anyways.  Never trust what the box tells you even if it
did list your listening ports 'properly'.

--
Randy


From gert at greenie.muc.de  Thu Sep 10 09:56:59 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Thu, 10 Sep 2009 15:56:59 +0200
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <20090910134905.M17612@fast-serv.com>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
	<20090910132204.GA14501@turbo.cisco.com>
	<20090910133233.GJ1508@greenie.muc.de>
	<20090910134905.M17612@fast-serv.com>
Message-ID: <20090910135659.GN1508@greenie.muc.de>

Hi,

On Thu, Sep 10, 2009 at 09:50:23AM -0400, Randy McAnally wrote:
> > So - to summarize this: "the only way to reliably detect what sockets
> > the box is listening on is to run nmap against it", right?
> 
> Regardless, run NMAP anyways.  Never trust what the box tells you even if it
> did list your listening ports 'properly'.

We do, but this is surprisingly difficult.  

Some of the ports are really only open from certain source IPs (like 
telnet/ssh if a vty ACL is used), so when nmap doesn't list anything, 
you never know "is *this* address not permitted to see the telnet port?" 
or "is the telnet service really not listening at all?"

For the things that I know about (telnet, ssh, http/s, ldp, bgp) I know
how to verify, but I was hoping for an easy way to see what else might
be lurking...

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090910/2879373b/attachment.bin>

From mark.meijerink at sara.nl  Thu Sep 10 09:09:43 2009
From: mark.meijerink at sara.nl (Mark Meijerink)
Date: Thu, 10 Sep 2009 15:09:43 +0200
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
 ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <20090910121617.GH1508@greenie.muc.de>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
Message-ID: <4AA8FA97.7070906@sara.nl>

Gert,

When I run the command I see al the active BGP/SSH/LDP sessions with Local Address, Foreign Address and state (ESTAB/LISTEN)

There is one entry in the table which I find a bit strange.
######## *.*                     *.*                    LISTEN

Listener on all ports???

Regards,
 Mark

Gert Doering wrote:
> Hi,
> 
> On Thu, Sep 10, 2009 at 01:48:46PM +0200, Mark Meijerink wrote:
>> When your run the show tcp brief all command you also see the listening ports.
>>
>> router#show tcp brief ?
>>   all  All end-points (even listeners)
> 
> Oh.  Cool.  For whatever reason, I overlooked this.
> 
> But anyway - my routers are lying to me.  They list *.179 just fine (BGP),
> but all the other interesting stuff (telnet, ssh, ldp) is not there...
> 
> gert
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090910/0112c2ac/attachment.bin>

From jay-ford at uiowa.edu  Thu Sep 10 11:24:38 2009
From: jay-ford at uiowa.edu (Jay Ford)
Date: Thu, 10 Sep 2009 10:24:38 -0500 (CDT)
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <200909101042.04053.mtinka@globaltransit.net>
References: <1F1F2AF9CD74144CAB1F5702D4F74A4E02E2E5F7@PHSXMB24.partners.org>
	<4AA78887.3000804@inex.ie>
	<200909101042.04053.mtinka@globaltransit.net>
Message-ID: <alpine.DEB.2.00.0909101022320.16508@seatpost.its.uiowa.edu>

On Thu, 10 Sep 2009, Mark Tinka wrote:
> IOS has had OSPF configuration just like IS-IS (i.e., under
> the interface), for quite a while now:
>
> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/ospfarea.html

It seems to be in only a few select releases:
    12.0(29)S
    12.3(11)T
    12.2(1)SB
    12.2(33)SRB
It's not in any release I run.  Ah, the chaos which is the IOS software 
tree!

________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-ford at uiowa.edu, phone: 319-335-5555, fax: 319-335-2951

From sthaug at nethelp.no  Thu Sep 10 12:28:25 2009
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Thu, 10 Sep 2009 18:28:25 +0200 (CEST)
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <alpine.DEB.2.00.0909101022320.16508@seatpost.its.uiowa.edu>
References: <4AA78887.3000804@inex.ie>
	<200909101042.04053.mtinka@globaltransit.net>
	<alpine.DEB.2.00.0909101022320.16508@seatpost.its.uiowa.edu>
Message-ID: <20090910.182825.74720045.sthaug@nethelp.no>

> > IOS has had OSPF configuration just like IS-IS (i.e., under
> > the interface), for quite a while now:
> >
> > http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/ospfarea.html
> 
> It seems to be in only a few select releases:
>     12.0(29)S
>     12.3(11)T
>     12.2(1)SB
>     12.2(33)SRB
> It's not in any release I run.  Ah, the chaos which is the IOS software 
> tree!

Now you know (one of the reasons) why some of us love our Juniper
M/MX/T routers :-)

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From gert at greenie.muc.de  Thu Sep 10 12:39:38 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Thu, 10 Sep 2009 18:39:38 +0200
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <20090910.182825.74720045.sthaug@nethelp.no>
References: <4AA78887.3000804@inex.ie>
	<200909101042.04053.mtinka@globaltransit.net>
	<alpine.DEB.2.00.0909101022320.16508@seatpost.its.uiowa.edu>
	<20090910.182825.74720045.sthaug@nethelp.no>
Message-ID: <20090910163938.GP1508@greenie.muc.de>

Hi,

On Thu, Sep 10, 2009 at 06:28:25PM +0200, sthaug at nethelp.no wrote:
> Now you know (one of the reasons) why some of us love our Juniper
> M/MX/T routers :-)

Why am I not suprised at all to see this comment? ;-))

Now, with Junipers, you have incompatible hardware thingies ("no, you
cannot use feature X with gige module Y").  But as far as software goes,
they are doing an amazing job - while Cisco is moving itself deeper and
deeper into the mud.

(Did I send my daily rant about the SR and SX split already?  But this 
is really just the tip of the 12.2/S/S* 12.3/T 12.4/T XR XE NX... iceberg)

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090910/480044c5/attachment.bin>

From mtinka at globaltransit.net  Thu Sep 10 11:46:56 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Thu, 10 Sep 2009 23:46:56 +0800
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <alpine.DEB.2.00.0909101022320.16508@seatpost.its.uiowa.edu>
References: <1F1F2AF9CD74144CAB1F5702D4F74A4E02E2E5F7@PHSXMB24.partners.org>
	<200909101042.04053.mtinka@globaltransit.net>
	<alpine.DEB.2.00.0909101022320.16508@seatpost.its.uiowa.edu>
Message-ID: <200909102347.06903.mtinka@globaltransit.net>

On Thursday 10 September 2009 11:24:38 pm Jay Ford wrote:

> It seems to be in only a few select releases:

I recall it being in other non-documented releases. I've 
used it in 12.4T for some workshops we gave in Asia and 
Africa.

I know I have it in 12.2(33)SRC, which means it's likely in 
SRD also. But yes, chaos, definitely...

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090910/be80a01b/attachment.bin>

From marcellobm at gmail.com  Thu Sep 10 13:43:19 2009
From: marcellobm at gmail.com (Marcello Barreto de Medeiros)
Date: Thu, 10 Sep 2009 14:43:19 -0300
Subject: [c-nsp] Max number of PacketClass and ServiceFlow
Message-ID: <20090910144319.56304753@mbarreto>

Hello Everybody,
I was looking for a way to control many CPE bandwidth using ServiceFlows.. but when I try to control more than 10 clients (I mean, put more than 10 UsPacketClass, 10 DsPacketClass, 10 UsServiceFlow and 10 DsServiceFlow) my Cable Modem doesn't come online, staying in init(o) (This I can see directly in my cmts - show cable modem 0013.711b.5498).

There are limitations like this??
My CMTS is a Cisco 7246VXR and i'm using docsis to encode. The Cable Modem is a motorola SurfBoard 5100/5101 Software Version: SB5100-2.3.3.0-SCM00-NOSH and SB5101-2.5.2.0-SCM01-NOSH-NNDMN.p7

Any ideas?

Thanks in advance.

From rodunn at cisco.com  Thu Sep 10 14:41:15 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Thu, 10 Sep 2009 14:41:15 -0400
Subject: [c-nsp] PAT usage stats...
Message-ID: <4AA9484B.5010805@cisco.com>

Curious...those of you running PAT for NAT, what is the average 
"translations per user" number you see active to determine the address 
pool given to PAT to overload on?

100 active per user at any give time, 50, ?

Rodney


From lsawyer at gci.com  Thu Sep 10 15:13:47 2009
From: lsawyer at gci.com (Leif Sawyer)
Date: Thu, 10 Sep 2009 11:13:47 -0800
Subject: [c-nsp] 3750 - power AC / DC
In-Reply-To: <4AA8D92F.1050800@skoal.name>
Message-ID: <38D04BF3A4B7B2499D19EB1DB54285EA0BE5BD30@FNB1EX01.gci.com>

Gergely Antal writes in response to 
> Vikas Sharma whom wrote:
> > Is there any command on 3750 (e and non-E) switches which can tell 
> > whether the power is AC or DC in the box? Like in 7206 we have sh 
> > environemnt..
> > 
> sh inventory raw...
> 
> NAME: "Switch 1 - Power Supply", DESCR: "FRU Power Supply"
> PID: C3K-PWR-265WAC    , VID: V01, SN:

Doesn't seem to work on the 3750's  that I have in my shop:


System image file is "flash:c3750me-i5-mz.122-46.SE.bin"
cisco ME-C3750-24TE (PowerPC405) processor (revision E0) with
118784K/12280K bytes of memory.

sho inven raw                                     
NAME: "1", DESCR: "ME-C3750-24TE"                                
PID: ME-C3750-24TE-M   , VID: V05, SN: CAT1027NJHJ               

NAME: "Pwr Supply A Container", DESCR: "Pwr Supply A Container"
PID:                   , VID:    , SN:                         

NAME: "Power Supply A", DESCR: "FRU Power Supply"
PID:                   , VID:    , SN:            

NAME: "Pwr Supply B Container", DESCR: "Pwr Supply B Container"
PID:                   , VID:    , SN:                         

NAME: "Power Supply B", DESCR: "FRU Power Supply"
PID:                   , VID:    , SN:            

NAME: "ME-C3750-24TE - Fan 0", DESCR: "ME-C3750-24TE - Fan 0"
PID:                   , VID:    , SN:                       


 

From leecalcote at gmail.com  Thu Sep 10 15:19:22 2009
From: leecalcote at gmail.com (Lee Calcote)
Date: Thu, 10 Sep 2009 14:19:22 -0500
Subject: [c-nsp] Monitoring the Nexus 7000 platform
Message-ID: <C6CEBB6A.D322%leecalcote@gmail.com>

Does anyone know what user account privilege level is needed to run netconf
commands on the Nexus 7000?

Thanks,
Lee

From rwest at zyedge.com  Thu Sep 10 15:02:37 2009
From: rwest at zyedge.com (Ryan West)
Date: Thu, 10 Sep 2009 15:02:37 -0400
Subject: [c-nsp] PAT usage stats...
In-Reply-To: <4AA9484B.5010805@cisco.com>
References: <4AA9484B.5010805@cisco.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124BF831BED@zy-ex1.zyedge.local>

Are you curious about IOS or Finesse or both?

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Rodney Dunn
Sent: Thursday, September 10, 2009 2:41 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] PAT usage stats...

Curious...those of you running PAT for NAT, what is the average 
"translations per user" number you see active to determine the address 
pool given to PAT to overload on?

100 active per user at any give time, 50, ?

Rodney

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From KaeglerM at tessco.com  Thu Sep 10 15:47:27 2009
From: KaeglerM at tessco.com (Kaegler, Mike)
Date: Thu, 10 Sep 2009 15:47:27 -0400
Subject: [c-nsp] PAT usage stats...
In-Reply-To: <4AA9484B.5010805@cisco.com>
Message-ID: <C6CED00F.161FD%KaeglerM@tessco.com>

Right now at one ~400 person site, I have 187 active local IPs sharing 1487
still-alive connections. Its your regular everyday sales cubefarm.
That's just shy of an average of 8 translations per active user. By those
numbers, you could have 8,000 salespeople on one PAT.

Personally, I'd cut it faaaaar before that. 800-1000 active, tops. Its not
"expensive" to start a second pool, and you never know when a sites deadline
for online sexual harassment training will be until 4:40pm when the phone
starts ringing...
-porkchop


On 9/10/09 2:41 PM, "Rodney Dunn" <rodunn at cisco.com> wrote:

> Curious...those of you running PAT for NAT, what is the average
> "translations per user" number you see active to determine the address
> pool given to PAT to overload on?
> 
> 100 active per user at any give time, 50, ?
> 
> Rodney
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 

-- 
Michael Kaegler, TESSCO Technologies: Engineering, 410 229 1295
Your wireless success, nothing less. http://www.tessco.com/


From brandon at burn.net  Thu Sep 10 16:24:54 2009
From: brandon at burn.net (Brandon Applegate)
Date: Thu, 10 Sep 2009 16:24:54 -0400 (EDT)
Subject: [c-nsp] Strange listening TCP ports on a 7600 ?
Message-ID: <alpine.DEB.1.00.0909101623390.31173@orbital.burn.net>

PORT     STATE SERVICE VERSION
2222/tcp open  unknown
4509/tcp open  unknown
4510/tcp open  unknown

Google/CCO etc fail me.  Various IOS show commands fail me.  Any idea what 
these are ?  Thanks.

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996
"SH1-0151.  This is the serial number, of our orbital gun."


From cisco at peakpeak.com  Thu Sep 10 17:43:32 2009
From: cisco at peakpeak.com (Security Team)
Date: Thu, 10 Sep 2009 15:43:32 -0600
Subject: [c-nsp] Weird Cat 6500 SUP2 problem
In-Reply-To: <mailman.877.1252430966.2225.cisco-nsp@puck.nether.net>
Message-ID: <C6CECF24.615E%cisco@peakpeak.com>

I am setting up a 6509 with SUP2's in RPR+ redundancy mode.  When I cycle
power on both supplies, the top SUP2 comes up fine. But the bottom one is
stuck in rommon

If I type "b" to boot the second one it comes up fine.

Am I doing something stupid?

Thx,
CJ




From mulitskiy at acedsl.com  Thu Sep 10 17:55:50 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Thu, 10 Sep 2009 17:55:50 -0400
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	of Service Vulnerabilities in Multiple Cisco Products
In-Reply-To: <200909081035.tcp24@psirt.cisco.com>
References: <200909081035.tcp24@psirt.cisco.com>
Message-ID: <200909101755.50648.mulitskiy@acedsl.com>

Hello,

I have a couple of 7200s that's currently running 12.4(23) (c7200-ik9s-mz.124-23.bin) which is listed 
vulnerable and I need to have some tcp port open (PPTP VPN), so I'm planning to upgrade to 
recommended 12.4(23b).
When I was comparing 12.4(23) and 12.4(23b) images in feature navigator I've noticed that
to my surpise 12.4(23b) doesn't support CAR which I need.
I loaded the image into dynamips and it seems to accept rate-limit commands, but it's hard to check
with dynamips whether it's really limiting anything. 
Unfortunately I don't have spare equipment to test, so I wonder if someone from cisco can comment 
on this. Is it just feature navigator typo or they really removed the feature in this rebuild?
Thanks a lot,

Michael

From mulitskiy at acedsl.com  Thu Sep 10 18:23:58 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Thu, 10 Sep 2009 18:23:58 -0400
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	of Service Vulnerabilities in Multiple Cisco Products
In-Reply-To: <200909101755.50648.mulitskiy@acedsl.com>
References: <200909081035.tcp24@psirt.cisco.com>
	<200909101755.50648.mulitskiy@acedsl.com>
Message-ID: <200909101823.58632.mulitskiy@acedsl.com>

dynamips testing seems to show that CAR is ok in 12.4(23b). 
I'd still like to hear a more definitive answer before i load it into production.
Thanks,

Michael

On Thursday 10 September 2009 05:55:50 pm Michael Ulitskiy wrote:
> Hello,
> 
> I have a couple of 7200s that's currently running 12.4(23) (c7200-ik9s-mz.124-23.bin) which is listed 
> vulnerable and I need to have some tcp port open (PPTP VPN), so I'm planning to upgrade to 
> recommended 12.4(23b).
> When I was comparing 12.4(23) and 12.4(23b) images in feature navigator I've noticed that
> to my surpise 12.4(23b) doesn't support CAR which I need.
> I loaded the image into dynamips and it seems to accept rate-limit commands, but it's hard to check
> with dynamips whether it's really limiting anything. 
> Unfortunately I don't have spare equipment to test, so I wonder if someone from cisco can comment 
> on this. Is it just feature navigator typo or they really removed the feature in this rebuild?
> Thanks a lot,
> 
> Michael
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 



From brad.henshaw at qcn.com.au  Thu Sep 10 20:35:07 2009
From: brad.henshaw at qcn.com.au (Brad Henshaw)
Date: Fri, 11 Sep 2009 10:35:07 +1000
Subject: [c-nsp] 3750 - power AC / DC
Message-ID: <8B25B862BC09784B9B74FB950D4F64D40F85A9@qcnapp01.corp.qcn>

Leif Sawyer wrote: 

>> sh inventory raw...
>> 
>> NAME: "Switch 1 - Power Supply", DESCR: "FRU Power Supply"
>> PID: C3K-PWR-265WAC    , VID: V01, SN:

> Doesn't seem to work on the 3750's  that I have in my shop:

'show env power' won't provide model numbers but should indicate whether
the PSUs are AC or DC. (note it's 'show env' not 'show environment')

Regards,
Brad

From justin at justinshore.com  Thu Sep 10 20:50:12 2009
From: justin at justinshore.com (Justin Shore)
Date: Thu, 10 Sep 2009 19:50:12 -0500
Subject: [c-nsp] 3750 - power AC / DC
In-Reply-To: <cca140000909100338g5de3f97bj3e1eddc18322d95c@mail.gmail.com>
References: <cca140000909100338g5de3f97bj3e1eddc18322d95c@mail.gmail.com>
Message-ID: <4AA99EC4.2030702@justinshore.com>

Vikas Sharma wrote:
> Hi,
> 
> Is there any command on 3750 (e and non-E) switches which can tell
> whether the power is AC or DC in the box? Like in 7206 we have sh
> environemnt..

Something along this line?

me3750-1.dc#sh ver | i IOS
Cisco IOS Software, C3750ME Software (C3750ME-I5K91-M), Version 
12.2(50)SE1, RELEASE SOFTWARE (fc2)
me3750-1.dc#
me3750-1.dc#
me3750-1.dc#sh env power
POWER SUPPLY A is DC OK
POWER SUPPLY B is DC OK

I don't know if that's dependent on a certain software rev or newer.  I 
tend to keep the MEs close to the most recent.

Justin




From ltd at cisco.com  Thu Sep 10 20:58:20 2009
From: ltd at cisco.com (Lincoln Dale)
Date: Fri, 11 Sep 2009 10:58:20 +1000
Subject: [c-nsp] Monitoring the Nexus 7000 platform
In-Reply-To: <C6CEBB6A.D322%leecalcote@gmail.com>
References: <C6CEBB6A.D322%leecalcote@gmail.com>
Message-ID: <29E4433F-1B92-4549-9B26-729F589494F2@cisco.com>

On 11/09/2009, at 5:19 AM, Lee Calcote wrote:

> Does anyone know what user account privilege level is needed to run  
> netconf
> commands on the Nexus 7000?

short answer:
it doesn't matter what priv you have.  that won't dictate whether you  
can use NetConf.

longer answer:
whether you're doing management/monitoring via CLI, SNMP, XML/Netconf,  
'roles" are mapped to what you can & cannot do.

regardless of whatever 'role' you have and what that role entitles you  
to do (maybe read only on some things, read/write on others), there is  
no specific "role" or "privildge level" required for NetConf.

if you're providing a priv level from an AAA server, that may well map  
to the built-in roles of "vdc-operator" / "network-operator" (for priv  
levels 0-14) or "vdc-admin" / "network-admin" (priv level 15).
but you can override all of that by using your own role(s) if you wish.


cheers,

lincoln.

From ras at e-gerbil.net  Thu Sep 10 22:37:55 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Thu, 10 Sep 2009 21:37:55 -0500
Subject: [c-nsp] SRC4 and rsvp
Message-ID: <20090911023755.GT51443@gerbil.cluepon.net>

Has anyone ever seen this issue... Just had an SRC4 7600 which was
rejecting rsvp reservations > 1G over SVI vlan interfaces, even though
the rsvp bandwidth was configured for 10G. Turned out that it was
because the "physical interface bandwidth" of the SVI interface (if
there is such a thing for a vlan interface) was defaulting to 1G, even 
though every show mpls and show ip rsvp command showed the interfaces as 
having 10G of bandwidth for the purposes of mpls. Worked around the 
issue by configuring "bandwidth 10000000" on the SVI.

And on that same subject, does anyone know when Cisco is going to fix 
all the hard-coded 10G limitations on this platform? You can't configure 
anything above 10G, no interface bandwidths, no rsvp bandwidths, no lsp 
reservations, nothing. Thats why I had the SVI's in the first place, 
because you need multiples to do > 10G port-channels. This seems like a 
serious design flaw that should really be on someone's road map to fix.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From link at pobox.com  Fri Sep 11 02:32:20 2009
From: link at pobox.com (Terje Bless)
Date: Fri, 11 Sep 2009 08:32:20 +0200
Subject: [c-nsp] Weird Cat 6500 SUP2 problem
In-Reply-To: <C6CECF24.615E%cisco@peakpeak.com>
References: <mailman.877.1252430966.2225.cisco-nsp@puck.nether.net> 
	<C6CECF24.615E%cisco@peakpeak.com>
Message-ID: <47ac005a0909102332p2eb4493dj855850952ca7271f@mail.gmail.com>

On Thu, Sep 10, 2009 at 11:43 PM, Security Team <cisco at peakpeak.com> wrote:
> I am setting up a 6509 with SUP2's in RPR+ redundancy mode. ?When I cycle
> power on both supplies, the top SUP2 comes up fine. But the bottom one is
> stuck in rommon
>
> If I type "b" to boot the second one it comes up fine.

If you pull the top Sup and powercycle, does the bottom Sup boot on
its own volition? Are you sure the two sups are identical hardware, or
could the bottom one have too little memory installed for the
(presumably common) IOS image? Does "sh bootvar" indicate any
differences between the two?

There's nothing about RPR+ that should cause the behaviour you
describe in normal operation.

HTH, -link

From p.mayers at imperial.ac.uk  Fri Sep 11 06:36:23 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Fri, 11 Sep 2009 11:36:23 +0100
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <20090910163938.GP1508@greenie.muc.de>
References: <4AA78887.3000804@inex.ie>	<200909101042.04053.mtinka@globaltransit.net>	<alpine.DEB.2.00.0909101022320.16508@seatpost.its.uiowa.edu>	<20090910.182825.74720045.sthaug@nethelp.no>
	<20090910163938.GP1508@greenie.muc.de>
Message-ID: <4AAA2827.30201@imperial.ac.uk>

Gert Doering wrote:
> Hi,
> 
> On Thu, Sep 10, 2009 at 06:28:25PM +0200, sthaug at nethelp.no wrote:
>> Now you know (one of the reasons) why some of us love our Juniper
>> M/MX/T routers :-)
> 
> Why am I not suprised at all to see this comment? ;-))
> 
> Now, with Junipers, you have incompatible hardware thingies ("no, you
> cannot use feature X with gige module Y").  But as far as software goes,
> they are doing an amazing job - while Cisco is moving itself deeper and
> deeper into the mud.

It's also worth emphasising that JunOS has a consistent cross-platform 
API for configuring their devices, and has done for a long while now.

Cisco's (embryonic) efforts seem to be falling firmly into the "one XML 
schema per device, but you can tunnel them all over netconf!"

I am not amused.

IOS sometimes feels like the very best that the 1980s has to offer... I 
mean, come on - I was actually IMPRESSED when 12.2(33)SX gave me "show 
run part router bgp ASNUM". Is that really the best we can do in 2009?

Sigh.

From nick at inex.ie  Fri Sep 11 07:37:34 2009
From: nick at inex.ie (Nick Hilliard)
Date: Fri, 11 Sep 2009 12:37:34 +0100
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <4AAA2827.30201@imperial.ac.uk>
References: <4AA78887.3000804@inex.ie>	<200909101042.04053.mtinka@globaltransit.net>	<alpine.DEB.2.00.0909101022320.16508@seatpost.its.uiowa.edu>	<20090910.182825.74720045.sthaug@nethelp.no>	<20090910163938.GP1508@greenie.muc.de>
	<4AAA2827.30201@imperial.ac.uk>
Message-ID: <4AAA367E.4040400@inex.ie>

On 11/09/2009 11:36, Phil Mayers wrote:
> IOS sometimes feels like the very best that the 1980s has to offer... I
> mean, come on - I was actually IMPRESSED when 12.2(33)SX gave me "show
> run part router bgp ASNUM". Is that really the best we can do in 2009?

I remember my cisco account manager in 1998 telling me that mainline IOS12 
would be fully modular.  W00h00!

Cisco is a very large company and it appears to have a lot of empires. 
Multiple empires beget balkanisation and lead to the sort of software train 
splits that we see.  I can imagine that it must be very difficult to keep 
any sort of control on source code, when you have all sorts of groups with 
all sorts of different product lines, different requirements and different 
time-scales.

Problem is, forking your code is like scrambling your egg.  Very easy to 
do, and it can even taste nice.  Unscrambling is not so easy, though.

The problem brings to mind something that Vijay Gill from Google said* 
recently about software development, albeit in a slightly different 
context:  "you require an insane amount of force of will".  If it's even 
possible to maintain some form of control over the IOS code base (and 
realistically, I don't know if it is, given the diversity of the product 
set), insane force of will would be required.

Nick
* 
http://www.theregister.co.uk/2009/06/27/google_mocks_microsoft_online_infrastructure/

From ml at kenweb.org  Fri Sep 11 08:04:27 2009
From: ml at kenweb.org (ML)
Date: Fri, 11 Sep 2009 08:04:27 -0400
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <4AAA367E.4040400@inex.ie>
References: <4AA78887.3000804@inex.ie>	<200909101042.04053.mtinka@globaltransit.net>	<alpine.DEB.2.00.0909101022320.16508@seatpost.its.uiowa.edu>	<20090910.182825.74720045.sthaug@nethelp.no>	<20090910163938.GP1508@greenie.muc.de>	<4AAA2827.30201@imperial.ac.uk>
	<4AAA367E.4040400@inex.ie>
Message-ID: <4AAA3CCB.2090805@kenweb.org>

Nick Hilliard wrote:

> Cisco is a very large company and it appears to have a lot of empires. 
> Multiple empires beget balkanisation and lead to the sort of software 
> train splits that we see.  I can imagine that it must be very difficult 
> to keep any sort of control on source code, when you have all sorts of 
> groups with all sorts of different product lines, different requirements 
> and different time-scales.

> Nick

Just to add another layer of IOS entropy..

I forget where I heard it but supposedly the same source code compiled 
by different people results in a different binary because people at 
Cisco maintain their own separate Makefiles with their own set of 
compiler flags. The "Compiled by.." line is more useful than you might 
think.

-ML




From dave.kruger at mtnbusiness.co.za  Fri Sep 11 08:09:23 2009
From: dave.kruger at mtnbusiness.co.za (Dave Kruger)
Date: Fri, 11 Sep 2009 14:09:23 +0200
Subject: [c-nsp] BFD on 7600
In-Reply-To: <4A8EBE87.2040105@justinshore.com>
References: <fad2fb270908210424o3fe74048k84b6b049970b5f2f@mail.gmail.com>
	<4A8EBE87.2040105@justinshore.com>
Message-ID: <4AAA3DF3.2010608@mtnbusiness.co.za>

Justin Shore wrote:
> MKS wrote:
>> Can you share your experience with BFD on the 7600 platform and sw
>> release?
>
> I use it and like it.

So did we (on SRD), until we hit bug CSCek38313. Fix coming in mid Nov
apparently

Regards,
Dave



From tomas at soitron.com  Fri Sep 11 08:27:12 2009
From: tomas at soitron.com (Daniska, Tomas)
Date: Fri, 11 Sep 2009 14:27:12 +0200
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <4AAA3CCB.2090805@kenweb.org>
References: <4AA78887.3000804@inex.ie>	<200909101042.04053.mtinka@globaltransit.net>	<alpine.DEB.2.00.0909101022320.16508@seatpost.its.uiowa.edu>	<20090910.182825.74720045.sthaug@nethelp.no>	<20090910163938.GP1508@greenie.muc.de>	<4AAA2827.30201@imperial.ac.uk><4AAA367E.4040400@inex.ie>
	<4AAA3CCB.2090805@kenweb.org>
Message-ID: <6B43981C32F8464CB24CEE209DA32BD3025A1F58@kenya.tronet.as>



> 
> Just to add another layer of IOS entropy..
> 
> I forget where I heard it but supposedly the same source code compiled
> by different people results in a different binary because people at
> Cisco maintain their own separate Makefiles with their own set of
> compiler flags. The "Compiled by.." line is more useful than you might
> think.
> 
> -ML

Well, in the good ol' days, maybe and possibly was. But these days
everything (including the makefiles) definitely should be part of the
code control process...

I hope so at least ;-)


--

deejay
 

__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4416
(20090911) __________

Tuto spravu preveril ESET NOD32 Antivirus.

http://www.eset.sk
 

From ross at kallisti.us  Fri Sep 11 08:57:40 2009
From: ross at kallisti.us (Ross Vandegrift)
Date: Fri, 11 Sep 2009 08:57:40 -0400
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <4AAA2827.30201@imperial.ac.uk>
References: <4AA78887.3000804@inex.ie>
	<200909101042.04053.mtinka@globaltransit.net>
	<alpine.DEB.2.00.0909101022320.16508@seatpost.its.uiowa.edu>
	<20090910.182825.74720045.sthaug@nethelp.no>
	<20090910163938.GP1508@greenie.muc.de>
	<4AAA2827.30201@imperial.ac.uk>
Message-ID: <20090911125740.GA3673@kallisti.us>

On Fri, Sep 11, 2009 at 11:36:23AM +0100, Phil Mayers wrote:
> It's also worth emphasising that JunOS has a consistent cross-platform  
> API for configuring their devices, and has done for a long while now.
>
> Cisco's (embryonic) efforts seem to be falling firmly into the "one XML  
> schema per device, but you can tunnel them all over netconf!"
>
> I am not amused.

To be fair, JUNOS has its share of warts here.  They split up
namespaces by JUNOS revision.  Since the XML namespace is considered
as part of the name of the tag, this means that though they have
consistent schemata, their tags are named differently between
versions.

Getting some XML handling tools to go through the gyrations to look
for "junos-interface" and not "junos93:junos-interface" and
"junos94:junos-interface" has been difficult for me - especially when
it's clear that they are the same kind of thing.  It's especially
annoying when the new version introduces no new sematics.

I don't honestly have any idea what the right approach is.  I've heard
rumors that JUNOS is moving away from versioned tags in v10 or 11, but
I don't know if I should believe that.

-- 
Ross Vandegrift
ross at kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie

From eng_mssk at hotmail.com  Fri Sep 11 10:18:04 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Fri, 11 Sep 2009 17:18:04 +0300
Subject: [c-nsp] SNMP v3
Message-ID: <BLU102-W25B3E61051B8A1A066E7C2FAE70@phx.gbl>


hey all

i have been reading the article from www.cisco.com
http://www.cisco.com/en/US/docs/ios/12_0t/12_0t3/feature/guide/Snmp3.html

and they mentioned the supported platforms and 2811 and 7600 for example are not mentioned is the list updated or they do not really support snmp v3 ?

_________________________________________________________________
Show them the way! Add maps and directions to your party invites. 
http://www.microsoft.com/windows/windowslive/products/events.aspx

From ddungui at gmail.com  Fri Sep 11 10:28:39 2009
From: ddungui at gmail.com (Donato Dunguihual Morales)
Date: Fri, 11 Sep 2009 10:28:39 -0400
Subject: [c-nsp] Cisco SCE 2020 and snmp  question
Message-ID: <4AAA5E97.7050106@gmail.com>

Hi,

I need to graph via snmp and  mrtg or rrdttool , ip traffic and 
protocols  for Cisco sce 2020 box.

I saw in  the web , the utility rtmcmd.   
http://www.cisco.com/en/US/products/ps6135/products_user_guide09186a00808165dd.html#o16507. 


I?m  trying to  run the scripts, in a linux server, with all  
requirements,  java , mrtg, rrdtool , but  i have the following error . 
Does anyone have any experience with this script or another form for 
generate a graph via snmp in SCE 2020?



#  ./rtmcmd.sh -S "X.X.X:X" -U user -P ***** --pqb-sce=X.X.X.X 
--source-dir=/templates --dest-dir=/rtm-output -c ./rtmcmd.cfg
connecting to X.X.X.X ... done
retrieving service configuration from SCE ... disconnecting from device 
... done
Failed to retrieve service configuration from SCE X.X.X.X. Aborting!



Thanks in advance
Donato

From ras at e-gerbil.net  Fri Sep 11 12:38:54 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Fri, 11 Sep 2009 11:38:54 -0500
Subject: [c-nsp] Catalyst vs. Nexus
In-Reply-To: <20090911125740.GA3673@kallisti.us>
References: <4AA78887.3000804@inex.ie>
	<200909101042.04053.mtinka@globaltransit.net>
	<alpine.DEB.2.00.0909101022320.16508@seatpost.its.uiowa.edu>
	<20090910.182825.74720045.sthaug@nethelp.no>
	<20090910163938.GP1508@greenie.muc.de>
	<4AAA2827.30201@imperial.ac.uk> <20090911125740.GA3673@kallisti.us>
Message-ID: <20090911163853.GV51443@gerbil.cluepon.net>

On Fri, Sep 11, 2009 at 08:57:40AM -0400, Ross Vandegrift wrote:
> To be fair, JUNOS has its share of warts here.  They split up
> namespaces by JUNOS revision.  Since the XML namespace is considered
> as part of the name of the tag, this means that though they have
> consistent schemata, their tags are named differently between
> versions.
> 
> Getting some XML handling tools to go through the gyrations to look
> for "junos-interface" and not "junos93:junos-interface" and
> "junos94:junos-interface" has been difficult for me - especially when
> it's clear that they are the same kind of thing.  It's especially
> annoying when the new version introduces no new sematics.

I've done a fair bit of work with JUNOS' XML interface (in netconf,
commit scripts, op scripts, etc), and I've got to say I've never seen
that issue before. I'm not aware of any requirement to use any version
specific tags. The biggest problem I have is handling different configs 
when there really is a change between versions, that is how to take 
advantage of new features when possible, when not every router has been 
upgraded to the new code yet.

But yes JUNOS certainly has its share of warts. They are going through
growing pains as they expand outside their traditional core router space
and try to become like Cisco. Unfortunately the end result is that they
are becoming like Cisco. And while they still have some of the most
advanced technology and smartest people out there, they also have a
large number of idiots mucking things up, and the number seems to go up 
every day. Still though, netconf has never crashed my router when I 
tried to use it, which is more than I can say for IOS. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From ray at oneunified.net  Fri Sep 11 14:12:22 2009
From: ray at oneunified.net (Ray Burkholder)
Date: Fri, 11 Sep 2009 15:12:22 -0300
Subject: [c-nsp] eigrp over atom
Message-ID: <009001ca330b$6918cbd0$3b4a6370$@net>

I'm having problems getting eigrp to talk over an mpls l2 link between two
cpe devices.

cpe -- 3550 -- 7206 -- 7206 -- 3560 -- cpe

cpe - 3550: access port on 3550
3550 - 7206: trunked port on vlan 100
7206 - 7206: mpls l2 xconnect 
7206 - 3560: trunked port on vlan 100
3560 - cpe: access port on 3560

I'm connecting two sites via pseudowires.  A configuration similar to the
following is on each 7206:

mpls export interval 5
mpls ldp loop-detection
mpls label protocol ldp

pseudowire-class ATOM-E
 encapsulation mpls
 interworking ethernet
!

interface FastEthernet4/0.100
 description MPLS ATOM Site 1
 encapsulation dot1Q 100
 xconnect x.x.x.x 100 pw-class ATOM-E
!

The link has been working fine and is working fine for regular udp and tcp
traffic.  The desire now is to run EIGRP over this link.  When configuring
each end for EIGRP with a /30 interface, hellos are getting dropped.  For
EIGRP, I believe hellos are multicast, which I think is the key issue.

The hellos appear to be dropped before reaching the other end. 

Is there additional configuration required to get eigrp hellos across the
link, or will it just not work, or is it supposed to 'just work'?

Ray



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


From howard at leadmon.net  Fri Sep 11 19:30:09 2009
From: howard at leadmon.net (Howard Leadmon)
Date: Fri, 11 Sep 2009 19:30:09 -0400
Subject: [c-nsp] Weird Cat 6500 SUP2 problem
In-Reply-To: <C6CECF24.615E%cisco@peakpeak.com>
References: <mailman.877.1252430966.2225.cisco-nsp@puck.nether.net>
	<C6CECF24.615E%cisco@peakpeak.com>
Message-ID: <032c01ca3337$cf89c190$6e9d44b0$@net>

 Make sure you have the bootvar's set right and the config register also
correct on both SUP's, as I  once had a SUP2 that wouldn't boot, just to
find out the confreg on the spare was not right, so it was just dropping to
ROMMON..


---
Howard Leadmon 


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Security Team
> Sent: Thursday, September 10, 2009 5:44 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Weird Cat 6500 SUP2 problem
> 
> I am setting up a 6509 with SUP2's in RPR+ redundancy mode.  When I cycle
> power on both supplies, the top SUP2 comes up fine. But the bottom one is
> stuck in rommon
> 
> If I type "b" to boot the second one it comes up fine.
> 
> Am I doing something stupid?
> 
> Thx,
> CJ
> 
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From kajtzu at a51.org  Sat Sep 12 05:39:30 2009
From: kajtzu at a51.org (Kaj Niemi)
Date: Sat, 12 Sep 2009 02:39:30 -0700
Subject: [c-nsp] SNMP v3
In-Reply-To: <BLU102-W25B3E61051B8A1A066E7C2FAE70@phx.gbl>
Message-ID: <C6D14702.422BC%kajtzu@a51.org>

Hi,


Check out Feature Navigator. Old release notes or feature guides are not
necessarily up to date w.r.t. what is supported/works and where. It'll work
given a recent enough IOS on 2800.



Kaj



> From: Mohammad Khalil <eng_mssk at hotmail.com>
> Date: Fri, 11 Sep 2009 07:18:04 -0700
> To: <cisco-nsp at puck.nether.net>
> Subject: [c-nsp] SNMP v3
> 
> hey all
> 
> i have been reading the article from www.cisco.com
> http://www.cisco.com/en/US/docs/ios/12_0t/12_0t3/feature/guide/Snmp3.html
> 
> and they mentioned the supported platforms and 2811 and 7600 for example are
> not mentioned is the list updated or they do not really support snmp v3 ?

From rjs at eng.gxn.net  Sat Sep 12 16:57:54 2009
From: rjs at eng.gxn.net (Rob Shakir)
Date: Sat, 12 Sep 2009 21:57:54 +0100
Subject: [c-nsp] Change VRF RD
In-Reply-To: <1252419663.6643.2.camel@abehat.net.rm.dk>
References: <4AA6324F.4060504@imperial.ac.uk>
	<1252419663.6643.2.camel@abehat.net.rm.dk>
Message-ID: <20090912205754.GF5351@cappuccino.rob.sh>

On Tue, Sep 08, 2009 at 04:21:03PM +0200, Peter Rathlev wrote:
> AFAIK there's no way around it. And AFAIK it's not Sup720 specific.

One thing that might be 7600/6500 specific on this matter is that we have been
seeing multiple crashes on both primary and secondary supervisors when changing
elements such as this on this platform running 12.2SR/12.2SX code.

We've figured the safest way is to configure this in parallel, then try and
clean up every line of VRF configuration relating to the old VRF. We've seen
crashes where there's memory corruption and the primary supervisor crashes. Or
where the line-by-line sync to the secondary in SSO causes it to crash. Both are
triggered by trying to remove the VRF RD and reconfigure it.

TAC haven't been able to reproduce either, so unfortunately we've got no bug ID.

Cheers,
Rob

-- 
Rob Shakir                      <rjs at eng.gxn.net>
Network Development Engineer    GX Networks/Vialtus Solutions
ddi: +44208 587 6077            mob: +44797 155 4098
pgp: 0xc07e6deb                 nic-hdl: RJS-RIPE

This email is subject to: http//www.vialtus.com/disclaimer.html


From gkg at gmx.de  Sun Sep 13 06:03:30 2009
From: gkg at gmx.de (Garry)
Date: Sun, 13 Sep 2009 12:03:30 +0200
Subject: [c-nsp] Vulnerable Software - search function?
Message-ID: <4AACC372.3000109@gmx.de>

I was wondering ... has Cisco ever had the idea of creating something
like the FN just for security advisories? I.e., I post the name of an
IOS image and get a list of known problems of that relase (or an "OK" if
none are known to date)?

After all, while we do have a pretty detailed overview of IOS releases
used on backbone/border/cpe devices, it is a pretty big zoo of versions
... sure, we keep a close eye on advisories as far as our border/core
routers are concerned ... but one can't watch out for everything ..  :(

-garry

From ml at kenweb.org  Sun Sep 13 09:44:35 2009
From: ml at kenweb.org (ML)
Date: Sun, 13 Sep 2009 09:44:35 -0400
Subject: [c-nsp] Vulnerable Software - search function?
In-Reply-To: <4AACC372.3000109@gmx.de>
References: <4AACC372.3000109@gmx.de>
Message-ID: <4AACF743.7010401@kenweb.org>

Use BugTraq

</sarcasm>

I'd settle for a more accurate BugTraq search.  BugTraq seems to always 
return results for bugs that don't effect my hardware/IOS combination. 
Assuming that platforms listed as effected are even accurate.

-ML

Garry wrote:
> I was wondering ... has Cisco ever had the idea of creating something
> like the FN just for security advisories? I.e., I post the name of an
> IOS image and get a list of known problems of that relase (or an "OK" if
> none are known to date)?
> 
> After all, while we do have a pretty detailed overview of IOS releases
> used on backbone/border/cpe devices, it is a pretty big zoo of versions
> ... sure, we keep a close eye on advisories as far as our border/core
> routers are concerned ... but one can't watch out for everything ..  :(
> 
> -garry
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



From mtinka at globaltransit.net  Sun Sep 13 10:21:22 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sun, 13 Sep 2009 22:21:22 +0800
Subject: [c-nsp] Vulnerable Software - search function?
In-Reply-To: <4AACC372.3000109@gmx.de>
References: <4AACC372.3000109@gmx.de>
Message-ID: <200909132221.22827.mtinka@globaltransit.net>

On Sunday 13 September 2009 06:03:30 pm Garry wrote:

> I was wondering ... has Cisco ever had the idea of
> creating something like the FN just for security
> advisories? I.e., I post the name of an IOS image and get
> a list of known problems of that relase (or an "OK" if
> none are known to date)?

You'd generally get this information from the Bug Toolkit.

This, however, is quite difficult to use, for me. I've never 
been able to really find what I'm looking for, while 
navigating it. I've found working with TAC and saving my bug 
ID's with notification way easier :-).

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090913/38fe3bd2/attachment.bin>

From oliver.gorwits at oucs.ox.ac.uk  Sun Sep 13 13:35:42 2009
From: oliver.gorwits at oucs.ox.ac.uk (Oliver Gorwits)
Date: Sun, 13 Sep 2009 18:35:42 +0100
Subject: [c-nsp] PAT usage stats...
In-Reply-To: <4AA9484B.5010805@cisco.com>
References: <4AA9484B.5010805@cisco.com>
Message-ID: <4AAD2D6E.6060506@oucs.ox.ac.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rodney Dunn wrote:
> Curious...those of you running PAT for NAT, what is the average 
> "translations per user" number you see active to determine the
> address pool given to PAT to overload on?
> 
> 100 active per user at any give time, 50, ?

Some mention of this in the first few slides of this presentation
about v6/NAT -related things:

http://www.nttv6.jp/~miyakawa/IETF72/

(with Google Maps example degrading as the number of permitted
connections drops below 30)

HTH,

- --
Oliver Gorwits, Network and Telecommunications Group,
Oxford University Computing Services
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKrS1u2NPq7pwWBt4RAhNJAJ9D+CUVCQ81dFmNuZEqtaeUhwRfWACgiGTP
MI5t5ZL2g31W2ursAMfzNkQ=
=zKZD
-----END PGP SIGNATURE-----

From chris at lavin-llc.com  Sun Sep 13 13:06:34 2009
From: chris at lavin-llc.com (chris at lavin-llc.com)
Date: Sun, 13 Sep 2009 13:06:34 -0400
Subject: [c-nsp] Vulnerable Software - search function?
Message-ID: <35363.1252861594@lavin-llc.com>

On Sun Sep 13  9:44 , ML  sent:

>Use BugTraq
>
>
>
>I'd settle for a more accurate BugTraq search.  BugTraq seems to always 
>return results for bugs that don't effect my hardware/IOS combination. 
>Assuming that platforms listed as effected are even accurate.
>
>-ML
>
>Garry wrote:
>> I was wondering ... has Cisco ever had the idea of creating something
>> like the FN just for security advisories? I.e., I post the name of an
>> IOS image and get a list of known problems of that relase (or an "OK" if
>> none are known to date)?
>> 
>> After all, while we do have a pretty detailed overview of IOS releases
>> used on backbone/border/cpe devices, it is a pretty big zoo of versions
>> ... sure, we keep a close eye on advisories as far as our border/core
>> routers are concerned ... but one can't watch out for everything ..  :(
>> 
>> -garry


I'm not a fan of the bug tool kit either. When analyzing 2 or 3 possible version yeilds 4,000+ hits per version it becomes an excercise in camping out 
for several days of reading. 

But what really aggrevates me is when you speak of these frustrations to the account team they try to sell you Advanced Services. It seems to me there 
is something fundamentally flawed when I have to pay an extra (and extremely high) price to have a Cisco AS person scrub their code versions for 
me. "Buy our gear and then pay us more to find a version of code to fit your needs".

-chris

From lists at quux.de  Sun Sep 13 13:29:37 2009
From: lists at quux.de (Jens Link)
Date: Sun, 13 Sep 2009 19:29:37 +0200
Subject: [c-nsp] Vulnerable Software - search function?
In-Reply-To: <4AACC372.3000109@gmx.de> (Garry's message of "Sun\,
	13 Sep 2009 12\:03\:30 +0200")
References: <4AACC372.3000109@gmx.de>
Message-ID: <877hw2vjlq.fsf@laphroiag.quux.de>

Garry <gkg at gmx.de> writes:

> I was wondering ... has Cisco ever had the idea of creating something
> like the FN just for security advisories? 

IIRC the last time I tried to use Cisco Works (a couple of years back)
there was a feature to check for Bugs in all IOSes used in a network
managed by Cisco Works. 

It always returned 0 Bugs.  I used Wireshark to troubleshoot this and
found out that CW was always trying to reach a specific website and the
server returned a 404.  

I know some people who would rely on the message by CW and who would
feel perfectly save.

Jens
-- 
-------------------------------------------------------------------------
| Foelderichstr. 40  | 13595 Berlin, Germany | +49-151-18721264         |
| http://www.quux.de | http://blog.quux.de   | jabber: jenslink at guug.de |
-------------------------------------------------------------------------

From kgraham at industrial-marshmallow.com  Sun Sep 13 22:28:43 2009
From: kgraham at industrial-marshmallow.com (Kevin Graham)
Date: Sun, 13 Sep 2009 19:28:43 -0700 (PDT)
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <20090910121617.GH1508@greenie.muc.de>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
Message-ID: <373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>

Sorry for the late response, had to dig through some old cases...


> But anyway - my routers are lying to me.  They list *.179 just fine (BGP),
> but all the other interesting stuff (telnet, ssh, ldp) is not there...

Last dug into this 2.5y ago (while looking into PSIRT cisco-sa-20070131-sip)
and the answer was:

     CSCdk86016
     Externally found moderate defect: Duplicate (D)
     Theres no way to see all listening ports

     CSCds10428
     Internally found moderate defect: Closed (C)
     Need netstat kind of support for IOS TCP/UDP

     It looks like after the business units analyzed everything they decided
     they were not going to move forward with this command.   

     "Currently we have the show tcp brief all which gives the lists the
     TCB's in the listening state. Also the netstat command is more generic
     and applicable to UNIX.  While it is desirable to have something like
     that, I don't see the exact benefits of the same."

Hopefully the new feature Eloy referred to will be more broadly available;
does anyone have the DDTS for its integration into 12.2S-derived trains?



From hank at efes.iucc.ac.il  Mon Sep 14 04:54:05 2009
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Mon, 14 Sep 2009 11:54:05 +0300
Subject: [c-nsp] Bug query broken?
Message-ID: <5.1.0.14.2.20090914115053.04fc0208@efes.iucc.ac.il>

I am trying the Bug Query toolkit:
http://tools.cisco.com/Support/BugToolKit/action.do?hdnAction=searchBugs
- specifing all IOS releases and trying keywords like "vlan" or "vty" which 
should have some hits but I keep getting:

No bugs meet your search criteria, try widening your search criteria and 
try again. Note: Bug Toolkit returns bugs modified within "The Last Year" 
by default. Try selecting "Any Time" or modifying other default search 
values under "Advanced Options."

Is it just me or is bug toolkit broken again?

Thanks,
Hank


From almog.purepeak at gmail.com  Mon Sep 14 07:02:13 2009
From: almog.purepeak at gmail.com (almog ohayon)
Date: Mon, 14 Sep 2009 14:02:13 +0300
Subject: [c-nsp] Cisco ASA Management
Message-ID: <3b53747c0909140402i74a3044g3aa98d746bd59c61@mail.gmail.com>

Hello Everyone,I want to know if there is a way to get access to internal
Cisco ASA interface from the "Outside world".
I want to achieve something similar to Loopback interface on Cisco routers.

Thanks,
--
Almog.

From mtinka at globaltransit.net  Mon Sep 14 07:19:49 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 14 Sep 2009 19:19:49 +0800
Subject: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!
In-Reply-To: <15CEC87F00BB7B4CA0E904C5FCF056463F0DAF00@EXCHANGENJ1.ds.tellurian.net>
References: <200812031357.24415.mtinka@globaltransit.net>
	<200812041037.02324.mtinka@globaltransit.net>
	<15CEC87F00BB7B4CA0E904C5FCF056463F0DAF00@EXCHANGENJ1.ds.tellurian.net>
Message-ID: <200909141919.57517.mtinka@globaltransit.net>

Thought I'd provide an update for the archives...

Many thanks to one folk who contacted me privately after 
Google'ing their way to this thread:

Frequent kernel panics have been experienced on all versions 
of Mac OS X 10.5 (Leopard) with VMware Fusion 2 and the 
Cisco VPN Client installed.

Workaround 1: disable IPv6 on Mac when working with the VPN
	    on a system that has VMware Fusion installed.

Workaround 2: uninstall VMware Fusion (may not be feasible
              for most).

Workaround 3: run the VPN inside VMware Fusion (doesn't
              protect traffic generated inside Mac OS X).

Cisco are aware about the problem, and said they won't fix 
the it since the Cisco VPN Client and virtual environments 
is unsupported (whatever that means). 

Suffice it to say, AFAIK, the Cisco VPN Client doesn't 
support IPv6.

Bug ID CSCsj38286 was filed for this case. Details as below:

=====

unity mac fails with parallels fusion and crossover

Symptoms
Parallels, Fusion, and CrossOver prevent the VPN Client from 
working properly.

Conditions
The VPN Client does not support the use of virtual 
environments.

Workarounds

Cisco VPN with Parallels:

* Install the VPN Client SW on MacOS.
* Configure Paralllels Networking. You'll probably want to 
use "shared networking" in Parallels. This causes Parallels 
to share a single MacOSX-side IP address by using NAT on all 
network traffic to/from the guest virtual machines/OS's. 
Some applications (IPTV) are NAT-intolerant and won't work 
in this case.

Alternately, instead of running Cisco VPN Client on MacOS, 
it can be run on the Windows side. Of course, then MacOSX 
would not be 'inside' the VPN but Windows would be. 

=====

Since Cisco don't plan to do anything about this, I'll have 
a chat with VMware and see what they say (considering it's 
clear that the Cisco VPN Client kernel extension is the one 
that crashes the system).

My private messenger also had this interesting bit to add:

"Also, worth nothing is that the "Local LAN access" feature 
in Cisco VPN client is IPv4 only. Which means that an 
attacker could access your computer over IPv6 and then be 
able to enter your company's network over the VPN connection 
from your machine. I've pointed that out too and Cisco hid 
behind the 'IPv6 is not supported' excuse."

Perhaps I can bug my account team, again :-).

Hope this is useful for some.

PS: I'm now running Snow Leopard (10.6.1). No crashes due to
    this, thus far, but who knows...

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090914/939caf88/attachment.bin>

From mtinka at globaltransit.net  Mon Sep 14 06:47:12 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 14 Sep 2009 18:47:12 +0800
Subject: [c-nsp] Cisco IPSec/VPN + DNS - Issue
Message-ID: <200909141847.22300.mtinka@globaltransit.net>

Hello all.

I'm having an issue with a Cisco IPSec/VPN connection that 
won't seem to shake.

I connect to a 2811 Cisco router configured with the EazyVPN 
infrastructure, using Cisco's VPN Client for Mac OS X 10.6.1 
(the latest Cisco VPN client for Mac, 4.9.01.0180). The 
router is running 12.4(24)T1 (using the "T" train to support 
SSL/VPN's)

When I connect to the VPN server, all is well. But it's 
guaranteed that after just about 10 minutes or so, DNS 
queries no longer work. The VPN would still be up, and I can 
connect to hosts via their IP address. DNS just bums out.

The workaround is to disconnect from the VPN server, and 
reconnect it. Of course, this isn't much of a solution, 
considering my IP address changes and I have re-establish 
some of my sessions to things.

I'm seeing the same issue on my Windows XP Professional home 
PC as well, so I can't chalk it down to Mac. Suffice it to 
say, I've had this problem since I started using Mac, i.e., 
since Tiger.

Anyone else seeing this? I'm using public IP addresses off 
the VPN server, so no NAT is going on. The DNS servers are 
sitting off the public network at the remote end of the VPN; 
changing them around hasn't yielded much.

The problem persists whether I connect to the VPN server 
over UDP or TCP.

All help appreciated.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090914/bc38c73a/attachment.bin>

From zivl at gilat.net  Mon Sep 14 07:25:29 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Mon, 14 Sep 2009 14:25:29 +0300
Subject: [c-nsp] Cisco ASA Management
In-Reply-To: <3b53747c0909140402i74a3044g3aa98d746bd59c61@mail.gmail.com>
References: <3b53747c0909140402i74a3044g3aa98d746bd59c61@mail.gmail.com>
Message-ID: <EC993E87D960A541A66BF21D62AA42A623015120A5@exch2k7.gilat.local>

Nope, no loopback, it's a firewall appliance!

Anyway, DMZ and/or static NAT/PAT could give you what you need

Worst case, set a vpn access of any kind (IPSec, SSL, PPTP)

HTH
Ziv


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of almog ohayon
Sent: Monday, September 14, 2009 2:02 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Cisco ASA Management

Hello Everyone,I want to know if there is a way to get access to internal
Cisco ASA interface from the "Outside world".
I want to achieve something similar to Loopback interface on Cisco routers.

Thanks,
--
Almog.
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************




 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************




From nick at inex.ie  Mon Sep 14 07:33:19 2009
From: nick at inex.ie (Nick Hilliard)
Date: Mon, 14 Sep 2009 12:33:19 +0100
Subject: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!
In-Reply-To: <200909141919.57517.mtinka@globaltransit.net>
References: <200812031357.24415.mtinka@globaltransit.net>	<200812041037.02324.mtinka@globaltransit.net>	<15CEC87F00BB7B4CA0E904C5FCF056463F0DAF00@EXCHANGENJ1.ds.tellurian.net>
	<200909141919.57517.mtinka@globaltransit.net>
Message-ID: <4AAE29FF.1050300@inex.ie>

On 14/09/2009 12:19, Mark Tinka wrote:
> PS: I'm now running Snow Leopard (10.6.1). No crashes due to
>      this, thus far, but who knows...

Unsurprisingly, VPN client doesn't run on a 64 bit snow leopard kernel.

However, VPN client works fine with Parallels desktop chugging away in the 
background on Leopard.  Haven't tried it on snow leopard, as I'm in 64 bit 
mode.

Nick

From A.L.M.Buxey at lboro.ac.uk  Mon Sep 14 07:45:49 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Mon, 14 Sep 2009 12:45:49 +0100
Subject: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!
In-Reply-To: <200909141919.57517.mtinka@globaltransit.net>
References: <200812031357.24415.mtinka@globaltransit.net>
	<200812041037.02324.mtinka@globaltransit.net>
	<15CEC87F00BB7B4CA0E904C5FCF056463F0DAF00@EXCHANGENJ1.ds.tellurian.net>
	<200909141919.57517.mtinka@globaltransit.net>
Message-ID: <20090914114549.GB24872@lboro.ac.uk>

hi,

'cisco does not support virtual environments' - yes 
we've heard the same thing.

however. forgive me if I'm wrong here but you were using
the VPN client in the main host and not in a virtual host
on the system - yes?  in which case its not a virtual environment
its a real 'level 0' host.

and their 'we dont support IPv6' tack is tactless and tacky.
not only do they only have business with a lot of people
because of their (often broken) IPv6 promises but they've got
IPv6 'support' in the client and in the server (not that the
management software can do much with IPv6 :-(  ) - we've
had multiple issues of late with their IPv6 support in
client software and in IOS - not happy with cisco at all
recently (i'd have to ask how they got the IPv6 Ready logo
for several of their products :-(  )

alan

From A.L.M.Buxey at lboro.ac.uk  Mon Sep 14 07:51:40 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Mon, 14 Sep 2009 12:51:40 +0100
Subject: [c-nsp] Cisco IPSec/VPN + DNS - Issue
In-Reply-To: <200909141847.22300.mtinka@globaltransit.net>
References: <200909141847.22300.mtinka@globaltransit.net>
Message-ID: <20090914115140.GC24872@lboro.ac.uk>

Hi,

I'd turn on full debugging on your client end and for your
client at the server end and see exactly what event goes on
just after those 10 minutes. I wonder if its a timeout
of somekind - eg perhaps DHCP renew and your system is being
given a DNS server that it cant talk to when VPN is running

alan

From vcappucc at cisco.com  Mon Sep 14 08:10:25 2009
From: vcappucc at cisco.com (Victor Cappuccio)
Date: Mon, 14 Sep 2009 15:10:25 +0300
Subject: [c-nsp] Cisco ASA Management
In-Reply-To: <3b53747c0909140402i74a3044g3aa98d746bd59c61@mail.gmail.com>
References: <3b53747c0909140402i74a3044g3aa98d746bd59c61@mail.gmail.com>
Message-ID: <002801ca3534$586891a0$0939b4e0$@com>

Hello Almog,

There are probably 1000 of ways to access a pix from the outside, one of
those ways is to use SSH.

pixfirewall# conf ter
pixfirewall(config)# int e0
pixfirewall(config-if)# ip add 192.168.1.1 255.255.255.0
pixfirewall(config-if)# nameif outside
INFO: Security level for "outside" set to 0 by default.
pixfirewall(config-if)# no sh
pixfirewall(config-if)# exit
pixfirewall(config)# hostname PIX
PIX(config)# domain-name onmynet.com
PIX(config)# crypto key generate rsa
INFO: The name for the keys will be: <Default-RSA-Key>
Keypair generation process begin. Please wait...
PIX(config)# ssh 0.0.0.0 0.0.0.0 outside
PIX(config)# show int ip brief
Interface                  IP-Address      OK? Method Status
Protocol
Ethernet0                  192.168.1.1     YES CONFIG up
up
Ethernet1                  unassigned      YES unset  administratively down
up
Ethernet2                  unassigned      YES unset  administratively down
up
Ethernet3                  unassigned      YES unset  administratively down
up
Ethernet4                  unassigned      YES unset  administratively down
up
PIX(config)# username cisco pass cisco
PIX(config)# %PIX-5-111008: User 'enable_15' executed the 'username cisco
password *' command.
PIX(config)# aaa authentication ssh console LOCAL
PIX(config)# %PIX-5-111008: User 'enable_15' executed the 'aaa
authentication ssh console LOCAL' command.

Now if we try to connect via the outside interface

PIX(config)# %PIX-7-710005: UDP request discarded from 192.168.1.2/138 to
outside:192.168.1.255/138
%PIX-6-302013: Built inbound TCP connection 10 for outside:192.168.1.2/4148
(192.168.1.2/4148) to NP Identity Ifc:192.168.1.1/22 (192.168.1.1/22)
Device ssh opened successfully.
SSH1: SSH client: IP = '192.168.1.2'  interface # = 1
SSH: host key initialised
SSH1: starting SSH control process
SSH1: Exchanging versions - SSH-2.0-Cisco-1.25

%PIX-6-315011: SSH session from 192.168.1.2 on interface outside for user
"ciscopix" disconnected by SSH server, reason: "Time-out activated" (0x3c)
%PIX-7-710005: TCP request discarded from 192.168.1.2/4148 to
outside:192.168.1.1/22
SSH1: send SSH message: outdata is NULL
%PIX-6-302014: Teardown TCP connection 9 for outside:192.168.1.2/4088 to NP
Identity Ifc:192.168.1.1/22 duration 0:01:20 bytes 919 TCP FINs

server version string:SSH-2.0-Cisco-1.25SSH1: receive SSH message: 83 (83)
SSH1: client version is - SSH-2.0-PuTTY_Release_0.60

client version string:SSH-2.0-PuTTY_Release_0.60SSH1: begin server key
generation
SSH0: Session disconnected by SSH server - error 0x3c "Time-out activated"
SSH1: complete server key generation, elapsed time = 2970 ms
SSH0: receive SSH message: [no message ID: variable *data is NULL]

SSH2 1: SSH2_MSG_KEXINIT sent
SSH2 1: SSH2_MSG_KEXINIT received
SSH2: kex: client->server aes256-cbc hmac-sha1 none
SSH2: kex: server->client aes256-cbc hmac-sha1 none
SSH2 1: expecting SSH2_MSG_KEXDH_INIT
SSH2 1: SSH2_MSG_KEXDH_INIT received
SSH2 1: signature length 143
SSH2: kex_derive_keys complete
SSH2 1: newkeys: mode 1
SSH2 1: SSH2_MSG_NEWKEYS sent
SSH2 1: waiting for SSH2_MSG_NEWKEYS
SSH2 1: newkeys: mode 0
SSH2 1: SSH2_MSG_NEWKEYS receivedSSH(cisco): user authen method is 'use
AAA', aaa server group ID = 1
SSH(cisco): user authen method is 'use AAA', aaa server group ID = 1
%PIX-6-113012: AAA user authentication Successful : local database : user =
cisco
%PIX-6-113008: AAA transaction status ACCEPT : user = cisco
%PIX-6-611101: User authentication succeeded: Uname: cisco
%PIX-6-611101: User authentication succeeded: Uname: cisco
%PIX-6-605005: Login permitted from 192.168.1.2/4148 to
outside:192.168.1.1/ssh for user "cisco"

SSH2 1: authentication successful for cisco
SSH2 1: channel open request
SSH2 1: pty-req request
SSH2 1: requested tty: xterm, height 19, width 91

SSH2 1: shell request
SSH2 1: shell message received
PIX(config)#

This is on my putty client
login as: cisco
cisco at 192.168.1.1's password:
Type help or '?' for a list of available commands.
PIX>
PIX>

Some good links

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note0918
6a0080094e71.shtml
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_61/config/bafw
cfg.htm


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of almog ohayon
Sent: lunes, 14 de septiembre de 2009 14:02
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Cisco ASA Management

Hello Everyone,I want to know if there is a way to get access to internal
Cisco ASA interface from the "Outside world".
I want to achieve something similar to Loopback interface on Cisco routers.

Thanks,
--
Almog.
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From asturluismi at gmail.com  Mon Sep 14 08:36:46 2009
From: asturluismi at gmail.com (luismi)
Date: Mon, 14 Sep 2009 14:36:46 +0200
Subject: [c-nsp] service policy and reflexive ACL
Message-ID: <1252931806.8526.1.camel@dsba-ipso>

Hi,

We have a design issue here.
We are not able to apply ACLs to create a reflexive ACL, so we are
thinking on the idea to apply a outbound service policy in an interface
and then build a reflexibe ACL based on the ACL matches of the service
policy.

Platform is 7600

Is that possible?




From rwest at zyedge.com  Mon Sep 14 08:41:22 2009
From: rwest at zyedge.com (Ryan West)
Date: Mon, 14 Sep 2009 08:41:22 -0400
Subject: [c-nsp] Cisco IPSec/VPN + DNS - Issue
In-Reply-To: <200909141847.22300.mtinka@globaltransit.net>
References: <200909141847.22300.mtinka@globaltransit.net>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124C103D977@zy-ex1.zyedge.local>

Mark,

What version of the Windows client are you running?

-ryan

From kajtzu at a51.org  Mon Sep 14 09:22:04 2009
From: kajtzu at a51.org (Kaj Niemi)
Date: Mon, 14 Sep 2009 06:22:04 -0700
Subject: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!
In-Reply-To: <20090914114549.GB24872@lboro.ac.uk>
Message-ID: <C6D41E2C.4237B%kajtzu@a51.org>

Hi,


The Cisco VPN Client (CVC) doesn't support IPv6 but AnyConnect SSL VPN
Client (AVC) does. It works well, too, even on OS X 10.6 - AVC is 2.3.0254
and the ASAs are running 8.0(x) and 8.2(x).



Kaj



> From: Alan Buxey <A.L.M.Buxey at lboro.ac.uk>
> Date: Mon, 14 Sep 2009 04:45:49 -0700
> To: Mark Tinka <mtinka at globaltransit.net>
> Cc: Vinny Abello <vinny at tellurian.com>, <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!
> 
> 
> and their 'we dont support IPv6' tack is tactless and tacky.
> not only do they only have business with a lot of people
> because of their (often broken) IPv6 promises but they've got
> IPv6 'support' in the client and in the server (not that the

From A.L.M.Buxey at lboro.ac.uk  Mon Sep 14 09:28:32 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Mon, 14 Sep 2009 14:28:32 +0100
Subject: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!
In-Reply-To: <C6D41E2C.4237B%kajtzu@a51.org>
References: <20090914114549.GB24872@lboro.ac.uk>
	<C6D41E2C.4237B%kajtzu@a51.org>
Message-ID: <20090914132832.GG24755@lboro.ac.uk>

Hi,

> The Cisco VPN Client (CVC) doesn't support IPv6 but AnyConnect SSL VPN
> Client (AVC) does. It works well, too, even on OS X 10.6 - AVC is 2.3.0254
> and the ASAs are running 8.0(x) and 8.2(x).

running 2.4 beta here because of other issues... but the ASDM still
isnt happy with IPv6 configuration present on the ASA  ;-)

alan

From kajtzu at a51.org  Mon Sep 14 09:30:20 2009
From: kajtzu at a51.org (Kaj Niemi)
Date: Mon, 14 Sep 2009 06:30:20 -0700
Subject: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!
In-Reply-To: <20090914132832.GG24755@lboro.ac.uk>
Message-ID: <C6D4201C.4237F%kajtzu@a51.org>


I've managed to be without ASDM so far.. I guess one _has_ to use it for the
WebVPN portal configuration though.. ;)


Kaj



> From: Alan Buxey <A.L.M.Buxey at lboro.ac.uk>
> Date: Mon, 14 Sep 2009 06:28:32 -0700
> To: Kaj Niemi <kajtzu at a51.org>
> Cc: Vinny Abello <vinny at tellurian.com>, <cisco-nsp at puck.nether.net>, Mark
> Tinka <mtinka at globaltransit.net>
> Subject: Re: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!
> 
> running 2.4 beta here because of other issues... but the ASDM still
> isnt happy with IPv6 configuration present on the ASA  ;-)

From gert at greenie.muc.de  Mon Sep 14 09:36:06 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 14 Sep 2009 15:36:06 +0200
Subject: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!
In-Reply-To: <C6D41E2C.4237B%kajtzu@a51.org>
References: <20090914114549.GB24872@lboro.ac.uk>
	<C6D41E2C.4237B%kajtzu@a51.org>
Message-ID: <20090914133606.GD1508@greenie.muc.de>

Hi,

On Mon, Sep 14, 2009 at 06:22:04AM -0700, Kaj Niemi wrote:
> The Cisco VPN Client (CVC) doesn't support IPv6 but AnyConnect SSL VPN
> Client (AVC) does. It works well, too, even on OS X 10.6 - AVC is 2.3.0254
> and the ASAs are running 8.0(x) and 8.2(x).

... if you have the appropriate license.

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090914/c15c3891/attachment.bin>

From rodunn at cisco.com  Mon Sep 14 09:38:39 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Mon, 14 Sep 2009 09:38:39 -0400
Subject: [c-nsp] PAT usage stats...
In-Reply-To: <C6CED00F.161FD%KaeglerM@tessco.com>
References: <C6CED00F.161FD%KaeglerM@tessco.com>
Message-ID: <4AAE475F.9000704@cisco.com>

Good data point.

Rodney



Kaegler, Mike wrote:
> Right now at one ~400 person site, I have 187 active local IPs sharing 1487
> still-alive connections. Its your regular everyday sales cubefarm.
> That's just shy of an average of 8 translations per active user. By those
> numbers, you could have 8,000 salespeople on one PAT.
> 
> Personally, I'd cut it faaaaar before that. 800-1000 active, tops. Its not
> "expensive" to start a second pool, and you never know when a sites deadline
> for online sexual harassment training will be until 4:40pm when the phone
> starts ringing...
> -porkchop
> 
> 
> On 9/10/09 2:41 PM, "Rodney Dunn" <rodunn at cisco.com> wrote:
> 
>> Curious...those of you running PAT for NAT, what is the average
>> "translations per user" number you see active to determine the address
>> pool given to PAT to overload on?
>>
>> 100 active per user at any give time, 50, ?
>>
>> Rodney
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
> 

From rwest at zyedge.com  Mon Sep 14 09:42:42 2009
From: rwest at zyedge.com (Ryan West)
Date: Mon, 14 Sep 2009 09:42:42 -0400
Subject: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!
In-Reply-To: <C6D4201C.4237F%kajtzu@a51.org>
References: <20090914132832.GG24755@lboro.ac.uk>
	<C6D4201C.4237F%kajtzu@a51.org>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124C103D98B@zy-ex1.zyedge.local>

Unfortunately, DAP as well.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Kaj Niemi
Sent: Monday, September 14, 2009 9:30 AM
To: Alan Buxey
Cc: Vinny Abello; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!


I've managed to be without ASDM so far.. I guess one _has_ to use it for the WebVPN portal configuration though.. ;)


Kaj



> From: Alan Buxey <A.L.M.Buxey at lboro.ac.uk>
> Date: Mon, 14 Sep 2009 06:28:32 -0700
> To: Kaj Niemi <kajtzu at a51.org>
> Cc: Vinny Abello <vinny at tellurian.com>, <cisco-nsp at puck.nether.net>, 
> Mark Tinka <mtinka at globaltransit.net>
> Subject: Re: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!
> 
> running 2.4 beta here because of other issues... but the ASDM still 
> isnt happy with IPv6 configuration present on the ASA  ;-)

From rodunn at cisco.com  Mon Sep 14 09:46:50 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Mon, 14 Sep 2009 09:46:50 -0400
Subject: [c-nsp] Strange listening TCP ports on a 7600 ?
In-Reply-To: <alpine.DEB.1.00.0909101623390.31173@orbital.burn.net>
References: <alpine.DEB.1.00.0909101623390.31173@orbital.burn.net>
Message-ID: <4AAE494A.1080601@cisco.com>

They are being closed back down via:

CSCtb90653    TCP Ports 2222, 4509, 4510 should not be opened by default

They are designed for some internal communication inside the box. Should 
not have been reachable outside the box.

Rodney







Brandon Applegate wrote:
> PORT     STATE SERVICE VERSION
> 2222/tcp open  unknown
> 4509/tcp open  unknown
> 4510/tcp open  unknown
> 
> Google/CCO etc fail me.  Various IOS show commands fail me.  Any idea 
> what these are ?  Thanks.
> 
> -- 
> Brandon Applegate - CCIE 10273
> PGP Key fingerprint:
> 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996
> "SH1-0151.  This is the serial number, of our orbital gun."
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From cgriffin at ufl.edu  Mon Sep 14 09:51:40 2009
From: cgriffin at ufl.edu (Chris Griffin)
Date: Mon, 14 Sep 2009 09:51:40 -0400
Subject: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!
In-Reply-To: <20090914133606.GD1508@greenie.muc.de>
References: <20090914114549.GB24872@lboro.ac.uk>
	<C6D41E2C.4237B%kajtzu@a51.org> <20090914133606.GD1508@greenie.muc.de>
Message-ID: <1252936300.3699.104.camel@empacher.cns.ufl.edu>

Starting with 8.2(1), Cisco now offers an Anyconnect only license called
"Anyconnect essentials" which allows you to use the Anyconnect client in
a very similar mode to the IPsec client.  Doesn't offer traditional web
based SSL services or posture assessment, but does allow you to support
64bit OS'es.  Cost is around $500 list for the 5550 and less for smaller
platforms as I recall...  MUCH cheaper than the old Anyconnect SSL
license.  Only problem is you must run 8.2, and its not quite there for
us yet, but we will be testing an interim release soon.

Tnx
Chris

On Mon, 2009-09-14 at 15:36 +0200, Gert Doering wrote:
> Hi,
> 
> On Mon, Sep 14, 2009 at 06:22:04AM -0700, Kaj Niemi wrote:
> > The Cisco VPN Client (CVC) doesn't support IPv6 but AnyConnect SSL VPN
> > Client (AVC) does. It works well, too, even on OS X 10.6 - AVC is 2.3.0254
> > and the ASAs are running 8.0(x) and 8.2(x).
> 
> ... if you have the appropriate license.
> 
> gert
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
-- 
Chris Griffin                           cgriffin at ufl.edu
Sr. Network Engineer - CCNP             Phone: (352) 273-1051
CNS - Network Services                  Fax:   (352) 392-9440
University of Florida/FLR               Gainesville, FL 32611


From rwest at zyedge.com  Mon Sep 14 09:51:41 2009
From: rwest at zyedge.com (Ryan West)
Date: Mon, 14 Sep 2009 09:51:41 -0400
Subject: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!
In-Reply-To: <20090914133606.GD1508@greenie.muc.de>
References: <20090914114549.GB24872@lboro.ac.uk>
	<C6D41E2C.4237B%kajtzu@a51.org> <20090914133606.GD1508@greenie.muc.de>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124C103D99C@zy-ex1.zyedge.local>

$100 for essentials on a 5510 isn't a bad deal, I still think it should be included in the base license after upgrading to 8.2(x)

-ryan

is 
> 2.3.0254 and the ASAs are running 8.0(x) and 8.2(x).

... if you have the appropriate license.

gert at net.informatik.tu-muenchen.de

From jared at puck.nether.net  Mon Sep 14 09:52:36 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 14 Sep 2009 09:52:36 -0400
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
	<373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>
Message-ID: <CD0195AB-DF6F-4B41-83BD-0E6F5F0BADF9@puck.nether.net>


On Sep 13, 2009, at 10:28 PM, Kevin Graham wrote:

> Sorry for the late response, had to dig through some old cases...
>
>
>> But anyway - my routers are lying to me.  They list *.179 just fine  
>> (BGP),
>> but all the other interesting stuff (telnet, ssh, ldp) is not  
>> there...
>
> Last dug into this 2.5y ago (while looking into PSIRT cisco- 
> sa-20070131-sip)
> and the answer was:
>
>     CSCdk86016
>     Externally found moderate defect: Duplicate (D)
>     Theres no way to see all listening ports
>
>     CSCds10428
>     Internally found moderate defect: Closed (C)
>     Need netstat kind of support for IOS TCP/UDP
>
>     It looks like after the business units analyzed everything they  
> decided
>     they were not going to move forward with this command.
>
>     "Currently we have the show tcp brief all which gives the lists  
> the
>     TCB's in the listening state. Also the netstat command is more  
> generic
>     and applicable to UNIX.  While it is desirable to have something  
> like
>     that, I don't see the exact benefits of the same."
>
> Hopefully the new feature Eloy referred to will be more broadly  
> available;
> does anyone have the DDTS for its integration into 12.2S-derived  
> trains?

Cisco does not manage software in a way that features and capabilities  
go to every platform/release.  Each platform runs its own release-ops  
team, with the rare exception of 'mainline'.  The platform specific  
trains eg: S/SX etc pick up mainline features via bulk syncs of code.

I've been asking for this capability for years, there is no way this  
is going to show up.  Cisco does not have the fortitude to keep a  
platform from shipping to pick up a central-eng/nsstg(itd) driven  
cleanup.  If something impairs the ability for cisco to recognize  
revenue, such as security/PSIRT issues it's unlikely to stop things  
from shipping.

ie: You need to ask your account team to prioritize these over you  
actually buying a device.  If it stops them from being able to sell  
you routers, it will get fixed.  If not, it's unlikely to have an  
impact.

While you're at it, ask for protected memory in the software.  It's  
not like ram/flash are expensive these days...

- Jared

From jason at lixfeld.ca  Mon Sep 14 09:16:06 2009
From: jason at lixfeld.ca (Jason Lixfeld)
Date: Mon, 14 Sep 2009 09:16:06 -0400
Subject: [c-nsp] 12.2(18)SXD to 12.2(33)SRB|C|D
Message-ID: <B32314DD-B600-40F0-A6EE-AD1D1A4736A5@lixfeld.ca>

As I look through the release notes, I thought I'd also ask here to  
see if anyone here has experience upgrading between these two versions  
on a 7600.  Any major gotchas?  Our box is pretty vanilla:  HA/SSO,  
VLANs, BGP4, per-port MTU, trust DSCP, LACP, OSPF, EIGRP, IPv4 only.

We're upgrading because we need hardware support for an ES20-GE3CXL  
for future use as an EVC termination point and RSVP based [M|V]PLS.   
Minimum requirements for the hardware is SRB, but seeing as how we are  
now at SRD do folks have some advice about the usability of some of  
the newer SR trains in conjunction with some of the aforementioned  
features?

Thanks in advance.

From dominic at broadconnect.ca  Mon Sep 14 09:42:10 2009
From: dominic at broadconnect.ca (Dominic Ian)
Date: Mon, 14 Sep 2009 09:42:10 -0400
Subject: [c-nsp] Delivering T1s via Channelised DS3?
Message-ID: <009701ca3541$29554180$050a14ac@dominic>


Hi Everyone,

I need to terminate T1s to a Cisco 7206VXR. The T1s will be hauled in via a channelised DS3, and I am looking for the right interface card to do the job. I came accross the PA-MC-2T3-EC, but for an interface card, the cost is really up there. Any suggestions as to other options?

And would there be a good reason for going with the PA-MC-2T3-EC, instead of the PA-MC-2T3+ ?


Thanks in advance.
Dominic

From mihai.campean at newcom.ro  Mon Sep 14 09:33:43 2009
From: mihai.campean at newcom.ro (Mihai Campean)
Date: Mon, 14 Sep 2009 16:33:43 +0300
Subject: [c-nsp] Problems creating a new BGP neighbor
Message-ID: <4AAE4637.9090203@newcom.ro>

Hi,
today I tried to create a new bgp neighbor, and the following message 
was prompted:
router1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
router1(config)#router bgp 1235
router1(config-router)#neighbor 1.2.3.5 remote-as 1235
*% Create the peer-group first

*Has anyone encountered this?
The machine is a 7600 series router, running Cisco IOS Software, 
c7600rsp72043_rp Software (c7600rsp72043_rp-ADVIPSERVICES-M), Version 
12.2(33)SRC1, RELEASE SOFTWARE (fc1)
Any ideea if this is a known BUG, and if there is some command on the 
IOS that forces you to add a new neighbor to a peer-group?
Thanks,

-- 
Best regards,

----------
Mihai Campean



From gert at greenie.muc.de  Mon Sep 14 10:36:23 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 14 Sep 2009 16:36:23 +0200
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <CD0195AB-DF6F-4B41-83BD-0E6F5F0BADF9@puck.nether.net>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
	<373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>
	<CD0195AB-DF6F-4B41-83BD-0E6F5F0BADF9@puck.nether.net>
Message-ID: <20090914143623.GE1508@greenie.muc.de>

Hi,

On Mon, Sep 14, 2009 at 09:52:36AM -0400, Jared Mauch wrote:
> While you're at it, ask for protected memory in the software.  It's  
> not like ram/flash are expensive these days...

Does "modular" have that?  Or not yet?

(I want to see modular on *all* IOS based platforms, and not as a 
somewhat-neglected step child on one specific niche platform that 
is actually fighting with another BU for line card support...  or if
that is not feasible, completely abandon IOS and provide XE or NX-OS
on *all* platforms)

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090914/b8e49dd1/attachment.bin>

From jared at puck.nether.net  Mon Sep 14 10:47:17 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 14 Sep 2009 10:47:17 -0400
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <20090914143623.GE1508@greenie.muc.de>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
	<373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>
	<CD0195AB-DF6F-4B41-83BD-0E6F5F0BADF9@puck.nether.net>
	<20090914143623.GE1508@greenie.muc.de>
Message-ID: <90758F88-6F72-4458-BB83-0917C31C2EB7@puck.nether.net>


On Sep 14, 2009, at 10:36 AM, Gert Doering wrote:

> Hi,
>
> On Mon, Sep 14, 2009 at 09:52:36AM -0400, Jared Mauch wrote:
>> While you're at it, ask for protected memory in the software.  It's
>> not like ram/flash are expensive these days...
>
> Does "modular" have that?  Or not yet?
>
> (I want to see modular on *all* IOS based platforms, and not as a
> somewhat-neglected step child on one specific niche platform that
> is actually fighting with another BU for line card support...  or if
> that is not feasible, completely abandon IOS and provide XE or NX-OS
> on *all* platforms)

The modular that showed up on 65xx was because 65xx saw value in it.   
No other platform sees the same value, meaning no protected memory for  
you.

It's sad when you see all the effort that went into the modular over  
the years being thrown away/ignored then keep having devices crash  
with more catastrophic outcomes and no usable debugging information.

- Jared

From mtinka at globaltransit.net  Mon Sep 14 10:34:06 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 14 Sep 2009 22:34:06 +0800
Subject: [c-nsp] Cisco IPSec/VPN + DNS - Issue
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E140124C103D977@zy-ex1.zyedge.local>
References: <200909141847.22300.mtinka@globaltransit.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E140124C103D977@zy-ex1.zyedge.local>
Message-ID: <200909142234.07425.mtinka@globaltransit.net>

On Monday 14 September 2009 08:41:22 pm Ryan West wrote:

> Mark,

Hi Ryan.

> What version of the Windows client are you running?

5.0.05.0290

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090914/f1048d64/attachment.bin>

From mtinka at globaltransit.net  Mon Sep 14 10:32:16 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 14 Sep 2009 22:32:16 +0800
Subject: [c-nsp] Cisco IPSec/VPN + DNS - Issue
In-Reply-To: <20090914115140.GC24872@lboro.ac.uk>
References: <200909141847.22300.mtinka@globaltransit.net>
	<20090914115140.GC24872@lboro.ac.uk>
Message-ID: <200909142232.23595.mtinka@globaltransit.net>

On Monday 14 September 2009 07:51:40 pm Alan Buxey wrote:

> Hi,

Hello Alan.

> I'd turn on full debugging on your client end and for
> your client at the server end and see exactly what event
> goes on just after those 10 minutes.

Already turned on the debug for the client on my end, but 
nothing that means anything.

I'll try on the server end - the hour could be un-godly, 
though, as it terminates a couple of folk from work :-).

> I wonder if its a
> timeout of somekind - eg perhaps DHCP renew and your
> system is being given a DNS server that it cant talk to
> when VPN is running

The public address is always static for the duration of the 
session. It's assigned from a pool configured on the router.

There's only 2 DNS servers pushed to the clients when they 
connect, and both are reachable from the router and the 
subnet it assigns to the clients.

Will let you know if anything interesting pops up on the 
router.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090914/0e2cb7a7/attachment.bin>

From me at falz.net  Mon Sep 14 10:51:04 2009
From: me at falz.net (Chris Wopat)
Date: Mon, 14 Sep 2009 09:51:04 -0500
Subject: [c-nsp] Delivering T1s via Channelised DS3?
Message-ID: <a62d17300909140751t2400f00eoee01a4a1db03b663@mail.gmail.com>

> From: "Dominic Ian" <dominic at broadconnect.ca>
>
> Hi Everyone,
>
> I need to terminate T1s to a Cisco 7206VXR. The T1s will be hauled in via a channelised
>  DS3, and I am looking for the right interface card to do the job. I came accross the
> PA-MC-2T3-EC, but for an interface card, the cost is really up there. Any suggestions as to
> other options?
>
> And would there be a good reason for going with the PA-MC-2T3-EC, instead of the PA-MC-2T3+ ?

The -EC card will offload MLPPP bundles that stay on the card. We use
non EC cards for this with an NPE-G1 and they work fine for what we
have on there, which is not that many bundles (single digits) and most
bundles have 2-3 T1's.

--Chris

From A.L.M.Buxey at lboro.ac.uk  Mon Sep 14 12:30:11 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Mon, 14 Sep 2009 17:30:11 +0100
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation
	Denial	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <20090914143623.GE1508@greenie.muc.de>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
	<373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>
	<CD0195AB-DF6F-4B41-83BD-0E6F5F0BADF9@puck.nether.net>
	<20090914143623.GE1508@greenie.muc.de>
Message-ID: <20090914163011.GC25690@lboro.ac.uk>

Hi,

> that is not feasible, completely abandon IOS and provide XE or NX-OS
> on *all* platforms)

NX-OS on all platforms? nothanks - some of us want functionality ;-)

alan

From ronan at iol.ie  Mon Sep 14 12:54:52 2009
From: ronan at iol.ie (Ronan Mullally)
Date: Mon, 14 Sep 2009 17:54:52 +0100 (IST)
Subject: [c-nsp] VPN Reverse Route Injection gateway in VRF
Message-ID: <alpine.DEB.2.00.0909141721040.3956@luggage>

(First post on the list, so please be gentle!)

I'm working on a VPN solution which creates multiple VRFs and assigns VPN
traffic into a particular VRF based on it's ISAKMP profile and a dynamic
crypto-map.  The application in hand is a CPE management network - each
CPE device builds a VPN tunnel back to a cisco router which constructs a
CPE VRF.

It all works works fine, up to a point.  I use Reverse Route Injection to
add routes into each VRF.  I've static routes configured in the VRF
directing outbound traffic via the correct front-door VRF:

 router> show crypto route
 Routes created in table CPE
 172.31.0.65/255.255.255.255 [1/0] via 1.2.3.4 tag 100
                                 on Port-channel1.99 RRI

 router> sh ip route vrf CPE

 S       172.31.0.65/32 [1/0] via 1.2.3.4
      1.0.0.0/23 is subnetted, 1 subnets
 S       1.2.2.0 [1/0] via 1.2.2.1, Port-channel1.99

1.2.3.4 represents public IP addresses.  I foresee a problem when I try
to terminate VPN tunnels from CPE devices that are not on public IP
addresses, but instead are part of another VRF using private IP ranges:

 router show crypto route
 Routes created in table CPE
 172.31.1.0/255.255.255.255 [1/0] via 10.0.0.102 tag 100
                                 on Port-channel1.1100 RRI

 router> sh ip route vrf CPE
 S       172.31.1.0/32 [1/0] via 10.0.0.102

I can use "reverse-route remote-peer A.B.C.D gateway" I get the route to
the remote host sent via the correct interface:

 router> sh ip route vrf CPE
 S       172.31.1.0/32 [1/0] via 10.0.0.102
       10.0.0.0/32 is subnetted, 1 subnets
 S       10.0.0.102 [1/0] via 10.0.0.4, Port-channel1.1100

My problem arises when we end up with overlapping address ranges in two
different (front door) VRFs, so I would expect to see something like:

 router> sh ip route vrf CPE
 S       172.31.1.0/32 [1/0] via 10.0.0.102
 S       172.31.1.1/32 [1/0] via 10.0.0.102
       10.0.0.0/32 is subnetted, 1 subnets
 S       10.0.0.102 [1/0] via 10.0.0.4, Port-channel1.1100
 S       10.0.0.102 [1/0] via 10.0.0.5, Port-channel1.1101

The first being in VRF A, the second in VRF B.

My questions are:

 - I expect this will be a problem, am I right? (ie there's no magic
   that will ensure packets for go via the right VRF and not get load
   balanced across two different VRFs, is there?)

 - Is there a way around the problem?  Careful address assignment to
   avoid collisions is all I can think of.

What I really need is to be able to specify an interface/VRF in the first
route, for example:

 router> sh ip route vrf CPE
 S       172.31.1.0/32 [1/0] via 10.0.0.102, Port-channel1.1100 (or vrf A)
 S       172.31.1.1/32 [1/0] via 10.0.0.102, Port-channel1.1101 (or vrf B)

Any advice would be very welcome.


-Ronan


From dbenson at swingpad.com  Mon Sep 14 13:31:54 2009
From: dbenson at swingpad.com (Dan Benson)
Date: Mon, 14 Sep 2009 13:31:54 -0400
Subject: [c-nsp] Cat 4948 NAT support
In-Reply-To: <mailman.68.1251925701.2225.cisco-nsp@puck.nether.net>
References: <mailman.68.1251925701.2225.cisco-nsp@puck.nether.net>
Message-ID: <1AD3CD5F-2BBD-4B9A-88A0-F3A2D0166257@swingpad.com>

I have a 4948 that I was hoping to upgrade a few systems with but I am  
dead in the water as it seems it does not support NAT.

According to the NAT matrix:

http://supportwiki.cisco.com/ViewWiki/index.php/Network_Address_Translation_Catalyst_Switch_Support_Matrix

This matrix seems very outdated so it would explain why the 4900  
product line is not listed.

Has anyone had any success in hacking these boxes to support NAT or am  
I am dreaming of the perfect cisco product?

Thanks. //db

Chassis Stats:

System image file is "bootflash:cat4500-entservices-mz.122-53.SG.bin"

cisco WS-C4948 (MPC8245) processor (revision 0) with 262144K bytes of  
memory.


From justin at justinshore.com  Mon Sep 14 14:33:09 2009
From: justin at justinshore.com (Justin Shore)
Date: Mon, 14 Sep 2009 13:33:09 -0500
Subject: [c-nsp] Cat 4948 NAT support
In-Reply-To: <1AD3CD5F-2BBD-4B9A-88A0-F3A2D0166257@swingpad.com>
References: <mailman.68.1251925701.2225.cisco-nsp@puck.nether.net>
	<1AD3CD5F-2BBD-4B9A-88A0-F3A2D0166257@swingpad.com>
Message-ID: <4AAE8C65.1090701@justinshore.com>

Dan Benson wrote:
> I have a 4948 that I was hoping to upgrade a few systems with but I am 
> dead in the water as it seems it does not support NAT.

I don't have any idea how to make it work but I do question doing NAT on 
a CAT to begin with.  Even if it did support NAT it would be done in 
software.  Someone firing up a simple BitTorrent client would likely be 
enough to bring it to its knees.  It's like doing NAT on the Sup in a 
65/7600.  A few Mbps is enough to bring the box down.  If NAT is a 
requirement then I'd look at doing it with a firewall or real router.

Best of luck
  Justin




From mandrews at bit0.com  Mon Sep 14 14:29:21 2009
From: mandrews at bit0.com (Mike Andrews)
Date: Mon, 14 Sep 2009 14:29:21 -0400
Subject: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!
In-Reply-To: <4AAE29FF.1050300@inex.ie>
References: <200812031357.24415.mtinka@globaltransit.net>	<200812041037.02324.mtinka@globaltransit.net>	<15CEC87F00BB7B4CA0E904C5FCF056463F0DAF00@EXCHANGENJ1.ds.tellurian.net>	<200909141919.57517.mtinka@globaltransit.net>
	<4AAE29FF.1050300@inex.ie>
Message-ID: <4AAE8B81.8020205@bit0.com>

Nick Hilliard wrote:
> On 14/09/2009 12:19, Mark Tinka wrote:
>> PS: I'm now running Snow Leopard (10.6.1). No crashes due to
>>      this, thus far, but who knows...
> 
> Unsurprisingly, VPN client doesn't run on a 64 bit snow leopard kernel.
> 
> However, VPN client works fine with Parallels desktop chugging away in 
> the background on Leopard.  Haven't tried it on snow leopard, as I'm in 
> 64 bit mode.

Kind of a side note here, but Apple now ships a Cisco-compatible IPSec 
client as part of Snow Leopard.  In System Preferences -> Network, if 
you add a new connection, and pick VPN as the type, "Cisco IPSec" is now 
one of the choices...  where previously only PPTP and L2TP-over-IPSec 
were.  Makes sense, as they've been shipping a similar client in the 
iPhone for a while now.

It may not have 100% feature parity (and I don't know if it supports 
IPv6), but it's close enough for us, and allowed me to uninstall Cisco's 
IPSec client that was causing frequent panics on boot for me under Leopard.

As others mentioned, the Anyconnect client also works well.  The only 
platform Anyconnect is giving me fits on is Vista...  XP 32-bit and 
64-bit Windows 7 run it fine...

From peter at rathlev.dk  Mon Sep 14 15:33:46 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Mon, 14 Sep 2009 21:33:46 +0200
Subject: [c-nsp] SNMP v3
In-Reply-To: <BLU102-W25B3E61051B8A1A066E7C2FAE70@phx.gbl>
References: <BLU102-W25B3E61051B8A1A066E7C2FAE70@phx.gbl>
Message-ID: <1252956826.2734.2.camel@abehat.net.rm.dk>

On Fri, 2009-09-11 at 17:18 +0300, Mohammad Khalil wrote:
> and they mentioned the supported platforms and 2811 and 7600 for
> example are not mentioned is the list updated or they do not really
> support snmp v3 ?

I know from experience that 2800 supports SNMPv3 in at least 12.2(40),
12.3(26) and 12.4(19) mainline releases. I am pretty certain that all
current releases support SNMPv3.

Regards,
Peter



From aptgetd at gmail.com  Mon Sep 14 15:30:59 2009
From: aptgetd at gmail.com (sky)
Date: Mon, 14 Sep 2009 12:30:59 -0700
Subject: [c-nsp] Migrating cisco ACS v3.3 to cisco 1113 ACS v4.2
Message-ID: <4AAE99F3.7090900@gmail.com>

Hi,

We are currently getting ready to migrate Cisco Secure ACS v3.3 (windows
server) to cisco 1113 ACS SE v4.2 (windows) appliance based solution.

Just wondering whether anyone has successfully migrated (exported) ACS
v3.3 database to ACS v4.2 database (imported) w/o having to upgrade v3.3
OS?

Is it possible to set replication partners between v3.3 (primary) and
v4.2 (secondary) or do they need to be on the version?

Any insight, pointers and feedback will be greatly appreciated.


thanks in advance,

regards,
sky




From merlyn at Geeks.ORG  Mon Sep 14 15:02:05 2009
From: merlyn at Geeks.ORG (Doug McIntyre)
Date: Mon, 14 Sep 2009 14:02:05 -0500
Subject: [c-nsp] Cat 4948 NAT support
In-Reply-To: <1AD3CD5F-2BBD-4B9A-88A0-F3A2D0166257@swingpad.com>
References: <mailman.68.1251925701.2225.cisco-nsp@puck.nether.net>
	<1AD3CD5F-2BBD-4B9A-88A0-F3A2D0166257@swingpad.com>
Message-ID: <20090914190205.GA57486@geeks.org>

On Mon, Sep 14, 2009 at 01:31:54PM -0400, Dan Benson wrote:
> I have a 4948 that I was hoping to upgrade a few systems with but I am dead 
> in the water as it seems it does not support NAT.
> 
> According to the NAT matrix:
> 
> http://supportwiki.cisco.com/ViewWiki/index.php/Network_Address_Translation_Catalyst_Switch_Support_Matrix
> 
> This matrix seems very outdated so it would explain why the 4900 product 
> line is not listed.


If you notice, the *only* products listed there that supports it is
the Cat6500.

The Cat 5k RSM was a seperate bolt-on router on a blade that slid into
the chassis, and wasn't the switch engine at all. Anyway that stuff is
old and dead (and was slow). 

So, don't go searching for switches that support NAT, the Cat6500 is it. 

Cisco leaves NAT to firewalls and routers, not switches. 

FWIW: The 4948 is still very current hardware. 




From kgraham at industrial-marshmallow.com  Mon Sep 14 15:53:52 2009
From: kgraham at industrial-marshmallow.com (Kevin Graham)
Date: Mon, 14 Sep 2009 12:53:52 -0700 (PDT)
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <90758F88-6F72-4458-BB83-0917C31C2EB7@puck.nether.net>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
	<373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>
	<CD0195AB-DF6F-4B41-83BD-0E6F5F0BADF9@puck.nether.net>
	<20090914143623.GE1508@greenie.muc.de>
	<90758F88-6F72-4458-BB83-0917C31C2EB7@puck.nether.net>
Message-ID: <569036.41095.qm@web1210.biz.mail.gq1.yahoo.com>

> It's sad when you see all the effort that went into the modular over the years 

> being thrown away/ignored then keep having devices crash with more catastrophic 
> outcomes and no usable debugging information.

Indeed, that too and the (much anticipated) promise of hot-patching never seemed
to materialize. To the best of my knowledge, there hasn't been a single PSIRT
announcement that was patchable and didn't require a traditional upgrade. Have I
not looked closely enough, or did I just misinterpret the original fanfare?



From kgraham at industrial-marshmallow.com  Mon Sep 14 16:07:34 2009
From: kgraham at industrial-marshmallow.com (Kevin Graham)
Date: Mon, 14 Sep 2009 13:07:34 -0700 (PDT)
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <20090914163011.GC25690@lboro.ac.uk>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
	<373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>
	<CD0195AB-DF6F-4B41-83BD-0E6F5F0BADF9@puck.nether.net>
	<20090914143623.GE1508@greenie.muc.de>
	<20090914163011.GC25690@lboro.ac.uk>
Message-ID: <693222.45234.qm@web1211.biz.mail.gq1.yahoo.com>



> > that is not feasible, completely abandon IOS and provide XE or NX-OS

> > on *all* platforms)
> 
> NX-OS on all platforms? nothanks - some of us want functionality ;-)

No, that's exactly the problem. The balkanization of the OS platforms
only amplifies this; "non-core" functionality such as IOS's incredibly
rich SNMP support is simply infeasible without the combined support of
a broad base of platforms.

I would eagerly and enthusiastically embrace NX-OS if there was an
interest in consolidating IOS/XR/XE in that direction. 

XE is the most promising migration path, IMHO, as they've embraced
modularity and a proprietary forwarding plane, while still providing
commonality with the control plane (I believe it is still that team's
intent to regularly re-sync with 12.2S for management features).


From clinton at scripty.com  Mon Sep 14 16:13:17 2009
From: clinton at scripty.com (Clinton Work)
Date: Mon, 14 Sep 2009 14:13:17 -0600
Subject: [c-nsp] Catalyst 4500/Sup5 - carrier-delay supported?
In-Reply-To: <4AA6D95C.7000706@scripty.com>
References: <4AA6D95C.7000706@scripty.com>
Message-ID: <4AAEA3DD.1050401@scripty.com>


I opened a TAC case and they confirmed after research with a DE that the 
"carrier-delay msec 100" interface command is configurable, but it 
doesn't do anything.  If your 4500 linecards don't have support for the 
port debounce capability then your out of luck. 

Clinton. 

Clinton Work wrote:
>
> I'm trying to figure out of the Catalyst 4500s running Sup5 with IOS 
> 12.2SG support the carrier-delay command. The interface capabilities 
> show that the old Catalyst link debounce feature isn't supported on 
> WS-X4306 GigE interfaces , however the switch allows you to configure 
> carrier-delay.  For example:


From kgraham at industrial-marshmallow.com  Mon Sep 14 16:15:26 2009
From: kgraham at industrial-marshmallow.com (Kevin Graham)
Date: Mon, 14 Sep 2009 13:15:26 -0700 (PDT)
Subject: [c-nsp] instabilities with SXI2?
In-Reply-To: <4A9CDB6A.6080607@imperial.ac.uk>
References: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>
	<4A9CDB6A.6080607@imperial.ac.uk>
Message-ID: <435002.85345.qm@web1214.biz.mail.gq1.yahoo.com>



> > TAC was pretty responsive, they have identified this as CSCtb27643.
> > It happens in SXI2, both modular and monolithic, and whether in VSS

> > or not, just when DFCs are in place. The ddts is not public so ask
> > your local team.
> 
> FWIW we just ran into this; TAC told me SXI2a would be released "shortly"

Hit it as well, after ~2 weeks of uptime, and then 4 crashes in the next 12
hours. According to TAC's diagnosis these were all due to the same bug,
which seems peculiar for a resource leak.

They hadn't seen this frequent of a crash caused by CSCtb27643 yet -- has
anyone else?



From nick at inex.ie  Mon Sep 14 16:17:54 2009
From: nick at inex.ie (Nick Hilliard)
Date: Mon, 14 Sep 2009 21:17:54 +0100
Subject: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!
In-Reply-To: <4AAE8B81.8020205@bit0.com>
References: <200812031357.24415.mtinka@globaltransit.net>	<200812041037.02324.mtinka@globaltransit.net>	<15CEC87F00BB7B4CA0E904C5FCF056463F0DAF00@EXCHANGENJ1.ds.tellurian.net>	<200909141919.57517.mtinka@globaltransit.net>	<4AAE29FF.1050300@inex.ie>
	<4AAE8B81.8020205@bit0.com>
Message-ID: <4AAEA4F2.2050606@inex.ie>

On 14/09/2009 19:29, Mike Andrews wrote:
> Kind of a side note here, but Apple now ships a Cisco-compatible IPSec
> client as part of Snow Leopard. In System Preferences -> Network, if you
> add a new connection, and pick VPN as the type, "Cisco IPSec" is now one
> of the choices... where previously only PPTP and L2TP-over-IPSec were.
> Makes sense, as they've been shipping a similar client in the iPhone for
> a while now.

Oh, so it does!  Sweet.  Well, that's VPN Client in the trash can and zero 
applications which tie me to a 32 bit kernel, except maybe a usb->serial 
driver.  Very cool.

> It may not have 100% feature parity (and I don't know if it supports
> IPv6), but it's close enough for us, and allowed me to uninstall Cisco's
> IPSec client that was causing frequent panics on boot for me under Leopard.

I'll have a look at ipv6 connectivity at some stage.  VPN Client doesn't 
support it, so it's not like lack of support would lose anything, but as 
the OS/X ipsec stack is KAME based, it should support ipv6 if the vpn 
concentrator does.

Nick

From ross at wtccommunications.ca  Mon Sep 14 16:23:39 2009
From: ross at wtccommunications.ca (Ross Halliday)
Date: Mon, 14 Sep 2009 16:23:39 -0400
Subject: [c-nsp] L2TPv3 with VLANs on one side (multipoint)
Message-ID: <151BC03492E46E4CB8D479E42CEF7890BEEE02@exchange.wtc.local>

Dear Internet Geniuses,

I am attempting to set up a solution for a customer where we provide a
multipoint Layer 2 bridge over several DSL connections. Unfortunately,
the DSL connections are leased and outside of our control. The wholesale
provider's network complained to no end believing there was a loop when
we simply tried to bridge them together.

So, I am looking towards L2TPv3. The equipment I've got to work with is
a 2821 and some 1721s for the L2TPv3 part. What I had intended to do was
have each of the remote sites with 1721s terminate their xconnect back
to a dot1q subinterface on the 2821, then blast that out somewhere and
hairpin the traffic with a bridge. Trouble is, when I move the xconnect
on the 2821 from the native Gi0/1 to something like Gi0/1.101 (and
change the switchport it's on to trunk mode) I lose connectivity. I am
aware of some other posters who have a similar setup (terminating
xconnects to the sub-interfaces) but I am not sure if those were tagged
or untagged on the remote end.

Terribad ASCII art of my lab setup:

 (untagged frame)
  V
 1721 Fas0
  V
 L2TPv3
  V
 1721 Eth0
  V
 2950 untagged vlan 100
  V
 2950 tagged vlan 100
  V
 2821 Gig0/0.100
  V
 L2TPv3

Now, here's what works on the 2821 end:

interface GigabitEthernet0/1
 description L2TPv3_out
 no ip address
 duplex full
 speed 100
 xconnect 172.17.1.10 1 encapsulation l2tpv3 manual pw-class test_PWC_1
  l2tp id 101 1
  l2tp hello test_CLASS_1

And here's what doesn't:

interface GigabitEthernet0/1
 description L2TPv3_VLANs
 no ip address
 duplex full
 speed 100
!
interface GigabitEthernet0/1.101
 description test_site_1
 encapsulation dot1Q 101
 xconnect 172.17.1.10 1 encapsulation l2tpv3 manual pw-class test_PWC_1
  l2tp id 101 1
  l2tp hello test_CLASS_1



The tunnels establish find on both variations, however on the tagged
version I don't get any traffic through the link and "sh l2tun tun
packets" indicates inbound only on each side.

Unfortunately the 1721s dont support 802.1q otherwise I'd give that a
go.

Any help would be appreciated, but please be kind to the newbie :)

Thanks


---
Ross Halliday
Network Operations
WTC Communications

Office: 613-547-6939 x203
Helpdesk: 866-547-6939 option 2
http://www.wtccommunications.ca 


From ras at e-gerbil.net  Mon Sep 14 16:39:53 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Mon, 14 Sep 2009 15:39:53 -0500
Subject: [c-nsp] 12.2(18)SXD to 12.2(33)SRB|C|D
In-Reply-To: <B32314DD-B600-40F0-A6EE-AD1D1A4736A5@lixfeld.ca>
References: <B32314DD-B600-40F0-A6EE-AD1D1A4736A5@lixfeld.ca>
Message-ID: <20090914203953.GE51443@gerbil.cluepon.net>

On Mon, Sep 14, 2009 at 09:16:06AM -0400, Jason Lixfeld wrote:
> As I look through the release notes, I thought I'd also ask here to  
> see if anyone here has experience upgrading between these two versions  
> on a 7600.  Any major gotchas?  Our box is pretty vanilla:  HA/SSO,  
> VLANs, BGP4, per-port MTU, trust DSCP, LACP, OSPF, EIGRP, IPv4 only.
> 
> We're upgrading because we need hardware support for an ES20-GE3CXL  
> for future use as an EVC termination point and RSVP based [M|V]PLS.   
> Minimum requirements for the hardware is SRB, but seeing as how we are  
> now at SRD do folks have some advice about the usability of some of  
> the newer SR trains in conjunction with some of the aforementioned  
> features?

SXD to SRD? That is a pretty major upgrade (and then some), and I've
seen nasty upgrade bugs with far far FAR smaller transitions. All I can
say is, do NOT attempt this without out of band.

Personally my recommendation for going forward is SRC (SRC4 is pretty
stable, all things considered). I haven't rechecked SRD recently, but
the early versions added some pretty serious bugs that weren't in SRC of
the same time-frame, and I can't find any compelling features which
necessitate the risk. There are also quite a few large networks who are
running large deployments of SRC, and it never hurts to have mass on
your side.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From gert at greenie.muc.de  Mon Sep 14 17:34:15 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 14 Sep 2009 23:34:15 +0200
Subject: [c-nsp] instabilities with SXI2?
In-Reply-To: <026e01ca357c$8ac6c660$a0545320$@com>
References: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>
	<4A9CDB6A.6080607@imperial.ac.uk>
	<435002.85345.qm@web1214.biz.mail.gq1.yahoo.com>
	<026e01ca357c$8ac6c660$a0545320$@com>
Message-ID: <20090914213415.GL1508@greenie.muc.de>

Hi,

On Mon, Sep 14, 2009 at 01:47:15PM -0700, Peter Kranz wrote:
> Given all this.. is the SXI2a a 'no go' for a production platform at this
> time? We are planning on doing a version refresh to address the TCP State
> manipulation issue, and considering moving to SXI2a from the SXF chain.

We're actually quite happy with SXI2 (since the initial thread starter
turned out to go away with proper grounding).  The crash bugs can be
worked around by turning off these diagnostic checks.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090914/b3217408/attachment.bin>

From pkranz at unwiredltd.com  Mon Sep 14 16:47:15 2009
From: pkranz at unwiredltd.com (Peter Kranz)
Date: Mon, 14 Sep 2009 13:47:15 -0700
Subject: [c-nsp] instabilities with SXI2?
In-Reply-To: <435002.85345.qm@web1214.biz.mail.gq1.yahoo.com>
References: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>	<4A9CDB6A.6080607@imperial.ac.uk>
	<435002.85345.qm@web1214.biz.mail.gq1.yahoo.com>
Message-ID: <026e01ca357c$8ac6c660$a0545320$@com>

Given all this.. is the SXI2a a 'no go' for a production platform at this
time? We are planning on doing a version refresh to address the TCP State
manipulation issue, and considering moving to SXI2a from the SXF chain.

Peter Kranz
Founder/CEO - Unwired Ltd
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-0000
pkranz at unwiredltd.com


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Kevin Graham
Sent: Monday, September 14, 2009 1:15 PM
To: Phil Mayers; Daniska Tomas
Cc: gert at greenie.muc.de; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] instabilities with SXI2?



> > TAC was pretty responsive, they have identified this as CSCtb27643.
> > It happens in SXI2, both modular and monolithic, and whether in VSS

> > or not, just when DFCs are in place. The ddts is not public so ask
> > your local team.
> 
> FWIW we just ran into this; TAC told me SXI2a would be released "shortly"

Hit it as well, after ~2 weeks of uptime, and then 4 crashes in the next 12
hours. According to TAC's diagnosis these were all due to the same bug,
which seems peculiar for a resource leak.

They hadn't seen this frequent of a crash caused by CSCtb27643 yet -- has
anyone else?


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From A.L.M.Buxey at lboro.ac.uk  Mon Sep 14 17:53:07 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Mon, 14 Sep 2009 22:53:07 +0100
Subject: [c-nsp] instabilities with SXI2?
In-Reply-To: <20090914213415.GL1508@greenie.muc.de>
References: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>
	<4A9CDB6A.6080607@imperial.ac.uk>
	<435002.85345.qm@web1214.biz.mail.gq1.yahoo.com>
	<026e01ca357c$8ac6c660$a0545320$@com>
	<20090914213415.GL1508@greenie.muc.de>
Message-ID: <20090914215307.GB26122@lboro.ac.uk>

Hi,

> We're actually quite happy with SXI2 (since the initial thread starter
> turned out to go away with proper grounding).  The crash bugs can be
> worked around by turning off these diagnostic checks.

and hope you dont hit another bug. waiting with intense interest
for SXI3 which should stop the instant crash when using ISIS with IPv6 :-(

alan

From A.L.M.Buxey at lboro.ac.uk  Mon Sep 14 17:56:17 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Mon, 14 Sep 2009 22:56:17 +0100
Subject: [c-nsp] Cisco VPN Client Causes Mac OS X Crash - Update!
In-Reply-To: <4AAE8B81.8020205@bit0.com>
References: <200812031357.24415.mtinka@globaltransit.net>
	<200812041037.02324.mtinka@globaltransit.net>
	<15CEC87F00BB7B4CA0E904C5FCF056463F0DAF00@EXCHANGENJ1.ds.tellurian.net>
	<200909141919.57517.mtinka@globaltransit.net>
	<4AAE29FF.1050300@inex.ie> <4AAE8B81.8020205@bit0.com>
Message-ID: <20090914215617.GC26122@lboro.ac.uk>

Hi,

> As others mentioned, the Anyconnect client also works well.  The only  
> platform Anyconnect is giving me fits on is Vista...  XP 32-bit and  
> 64-bit Windows 7 run it fine...

really? 32bit Vista okay with AnyConnect here - but not okay with 64bit Vista
(so interesting that it works with 64bit Win7 - I wonder if some
32bit WinXP backwards compat code is kicking into action to help it run?

alan

From jared at puck.nether.net  Mon Sep 14 18:27:25 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 14 Sep 2009 18:27:25 -0400
Subject: [c-nsp] instabilities with SXI2?
In-Reply-To: <20090914215307.GB26122@lboro.ac.uk>
References: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>
	<4A9CDB6A.6080607@imperial.ac.uk>
	<435002.85345.qm@web1214.biz.mail.gq1.yahoo.com>
	<026e01ca357c$8ac6c660$a0545320$@com>
	<20090914213415.GL1508@greenie.muc.de>
	<20090914215307.GB26122@lboro.ac.uk>
Message-ID: <6D1685A7-18DE-4A1F-9D77-63AA61EFCCA9@puck.nether.net>


On Sep 14, 2009, at 5:53 PM, Alan Buxey wrote:

> Hi,
>
>> We're actually quite happy with SXI2 (since the initial thread  
>> starter
>> turned out to go away with proper grounding).  The crash bugs can be
>> worked around by turning off these diagnostic checks.
>
> and hope you dont hit another bug. waiting with intense interest
> for SXI3 which should stop the instant crash when using ISIS with  
> IPv6 :-(

I have not seen an issue with ISIS + IPv6,is this with MT enabled?

I have a long laundry list of bugs in SXI2, including one that I've  
not quite yet isolated when you have several levels of recursion on  
routes causing it to take quite some time to finally settle down after  
a network event.  We don't see the same problem in pre-cef/mfi code  
(ie: SXF) but do see poor convergence properties in SXH/SXI.

	- Jared

From Charlie.Greenaway at btinet.bt.com  Mon Sep 14 19:25:36 2009
From: Charlie.Greenaway at btinet.bt.com (Charlie Greenaway)
Date: Tue, 15 Sep 2009 00:25:36 +0100
Subject: [c-nsp] MPLS TE Fast Re-route
Message-ID: <7EA99F102607DF43BDF25CC68475008703DDDE35@lhmail.btinet.local>

Hi,

I have a question on MPLS TE and Fast Re-Route.

I have a test network and I want to check that the behaviour I am seeing is correct.

When you set-up an backup path for patch-protection, it would seem that RSVP sends signalling messages down the backup path to reserve the bandwidth.  However, it does not seem to build an LSP and assign labels to it until the primary path breaks.  Is this correct?  Has anyone got any advice on using MPLS FRR?

Thanks,

Charlie G



Charlie Greenaway - CCIE#11226 (Security/R&S)

Solutions Architect | BT iNet | 
Email: charlie.greenaway at btinet.bt.com | Web:?www.btinet.bt.com 



This electronic message contains information from BT iNet, which may be privileged or confidential.  The information is intended for use only by the individual(s) or entity named above.  If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is strictly prohibited.  If you have received this e-mail in error, please let me know immediately on the e-mail address above. 
Activity and use of the BT iNet e-mail system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.

From dale.shaw+cisco-nsp at gmail.com  Tue Sep 15 03:18:24 2009
From: dale.shaw+cisco-nsp at gmail.com (Dale Shaw)
Date: Tue, 15 Sep 2009 17:18:24 +1000
Subject: [c-nsp] 7200/NPE-G1 WCCPv2 performance - L2 redirect vs GRE
In-Reply-To: <3329cbb40909150012u18bc5fa1j965949772587c722@mail.gmail.com>
References: <3329cbb40909150012u18bc5fa1j965949772587c722@mail.gmail.com>
Message-ID: <3329cbb40909150018i5e3d7a29v7d9a573802ed9c41@mail.gmail.com>

Hi all,

Does anyone know whether there is any notable performance difference
with WCCPv2 using L2 redirect vs GRE as a packet forwarding method on
7200s? (NPE-400, NPE-G1,
NPE-G2)?

WCCPv2 is a heavy user of processor cycles on our 7200s so I'm looking
at ways to reduce the impact without performing major heart surgery.
Currently we use GRE but our WCCP-speaking systems (cisco WAAS) are L2
adjacent so L2 redirect is a feasible option.

I'm not familiar enough with the guts of CEF to know whether this is
likely to make a big difference, but I guess there has to be less work
in re-writing a MAC header than completely encapsulating a packet.

cheers,
Dale

From chrimaso at cisco.com  Tue Sep 15 04:16:14 2009
From: chrimaso at cisco.com (Chris Mason (chrimaso))
Date: Tue, 15 Sep 2009 10:16:14 +0200
Subject: [c-nsp] Problems creating a new BGP neighbor
In-Reply-To: <4AAE4637.9090203@newcom.ro>
References: <4AAE4637.9090203@newcom.ro>
Message-ID: <1B1C4BD9D5034E42B736327F0D4FB2C539D714@XMB-AMS-113.cisco.com>

Hi Mihai,

Check out CSCsz68307 - this occurs when someone attempts to configure an invalid IP address as a BGP peer - after that you are unable to create any additional peers as you get the error message "*% Create the peer-group first".

To resolve the problem you either need to reload the box or configure "no parser cache" - the latter being more preferable.

Hope that helps,
Chris

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mihai Campean
Sent: 14 September 2009 14:34
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Problems creating a new BGP neighbor

Hi,
today I tried to create a new bgp neighbor, and the following message 
was prompted:
router1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
router1(config)#router bgp 1235
router1(config-router)#neighbor 1.2.3.5 remote-as 1235
*% Create the peer-group first

*Has anyone encountered this?
The machine is a 7600 series router, running Cisco IOS Software, 
c7600rsp72043_rp Software (c7600rsp72043_rp-ADVIPSERVICES-M), Version 
12.2(33)SRC1, RELEASE SOFTWARE (fc1)
Any ideea if this is a known BUG, and if there is some command on the 
IOS that forces you to add a new neighbor to a peer-group?
Thanks,

-- 
Best regards,

----------
Mihai Campean


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 821 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090915/8e2e117b/attachment.bin>

From mihai.campean at newcom.ro  Tue Sep 15 04:51:04 2009
From: mihai.campean at newcom.ro (Mihai Campean)
Date: Tue, 15 Sep 2009 11:51:04 +0300
Subject: [c-nsp] Problems creating a new BGP neighbor
In-Reply-To: <1B1C4BD9D5034E42B736327F0D4FB2C539D714@XMB-AMS-113.cisco.com>
References: <4AAE4637.9090203@newcom.ro>
	<1B1C4BD9D5034E42B736327F0D4FB2C539D714@XMB-AMS-113.cisco.com>
Message-ID: <4AAF5578.7000307@newcom.ro>

Hi Chris,
I reloaded the box this morning, but I'll configure the command in order 
to prevent further issues :)
Thanks:)

Chris Mason (chrimaso) wrote:
> Hi Mihai,
>
> Check out CSCsz68307 - this occurs when someone attempts to configure an invalid IP address as a BGP peer - after that you are unable to create any additional peers as you get the error message "*% Create the peer-group first".
>
> To resolve the problem you either need to reload the box or configure "no parser cache" - the latter being more preferable.
>
> Hope that helps,
> Chris
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mihai Campean
> Sent: 14 September 2009 14:34
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Problems creating a new BGP neighbor
>
> Hi,
> today I tried to create a new bgp neighbor, and the following message 
> was prompted:
> router1#conf t
> Enter configuration commands, one per line.  End with CNTL/Z.
> router1(config)#router bgp 1235
> router1(config-router)#neighbor 1.2.3.5 remote-as 1235
> *% Create the peer-group first
>
> *Has anyone encountered this?
> The machine is a 7600 series router, running Cisco IOS Software, 
> c7600rsp72043_rp Software (c7600rsp72043_rp-ADVIPSERVICES-M), Version 
> 12.2(33)SRC1, RELEASE SOFTWARE (fc1)
> Any ideea if this is a known BUG, and if there is some command on the 
> IOS that forces you to add a new neighbor to a peer-group?
> Thanks,
>
>   

-- 
Best regards,

----------
Mihai Campean



From mtinka at globaltransit.net  Tue Sep 15 06:48:19 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Tue, 15 Sep 2009 18:48:19 +0800
Subject: [c-nsp] instabilities with SXI2?
In-Reply-To: <20090914215307.GB26122@lboro.ac.uk>
References: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>
	<20090914213415.GL1508@greenie.muc.de>
	<20090914215307.GB26122@lboro.ac.uk>
Message-ID: <200909151848.20448.mtinka@globaltransit.net>

On Tuesday 15 September 2009 05:53:07 am Alan Buxey wrote:

> and hope you dont hit another bug. waiting with intense
> interest for SXI3 which should stop the instant crash
> when using ISIS with IPv6 :-(

Are you seeing this in SXI2?

We are planning to move to SXI2a at the end of October.

We are currently running SXH3 with IS-IS supporting both v4 
and v6 address families. No issues with that today.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090915/5a81209a/attachment.bin>

From mtinka at globaltransit.net  Tue Sep 15 06:45:16 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Tue, 15 Sep 2009 18:45:16 +0800
Subject: [c-nsp] 12.2(18)SXD to 12.2(33)SRB|C|D
In-Reply-To: <20090914203953.GE51443@gerbil.cluepon.net>
References: <B32314DD-B600-40F0-A6EE-AD1D1A4736A5@lixfeld.ca>
	<20090914203953.GE51443@gerbil.cluepon.net>
Message-ID: <200909151845.51812.mtinka@globaltransit.net>

On Tuesday 15 September 2009 04:39:53 am Richard A 
Steenbergen wrote:

> Personally my recommendation for going forward is SRC
> (SRC4 is pretty stable, all things considered).

Would also recommend SRC; we have it largely deployed on a 
number of 7200's.

SRC4 is stable, but a few issues, that will be resolved in 
SRC5, hound us. Nothing major, probably not faced by many 
others...

Point is, SRC is probably a more mature release.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090915/077ce12c/attachment.bin>

From vedlabs at gmail.com  Tue Sep 15 08:17:17 2009
From: vedlabs at gmail.com (Ved Labs)
Date: Tue, 15 Sep 2009 17:47:17 +0530
Subject: [c-nsp] dampening for VPNv4
In-Reply-To: <7db92dcc0909022314y33ad8ecch791e606fed8c8e3e@mail.gmail.com>
References: <7db92dcc0908290435s2c9b32eerc64f076eea1f17a2@mail.gmail.com>
	<7db92dcc0908312241w6951ead8x77efa9b781484414@mail.gmail.com>
	<4422cf660909010247y324ab799vae31e03402d6cf3a@mail.gmail.com>
	<7db92dcc0909022314y33ad8ecch791e606fed8c8e3e@mail.gmail.com>
Message-ID: <7db92dcc0909150517i5de25d64sd8148f86ecffc9be@mail.gmail.com>

the culprit was ....CSCsy58115
what a relief !!!!

On Thu, Sep 3, 2009 at 11:44 AM, Ved Labs <vedlabs at gmail.com> wrote:

> Thanks Ben for the directions .
>
> I enabled the bgp dampening for VPNv4 address-family .
> It helped to some extent to see the flapped statistics from the CE .
> I blocked one of the /16 network , which was flapping at a higher rate ,
> coming from CE.
>
> Still i do not see significant improvement in the CPU utilisation due to
> "BGP router" process.
>
> i can see some changes in prefixes recieved for the VPNv4 route reflector
> session.
> and there are around 20000 prefixes coming from the VPVv4 RR.
> How do i find the culprit
>
> The router is 7206 with NPE-G1 .
> Could there be a memory or hardware limilitation also or some bug.
>
> Thanks,
> Ved.
>
>
>
>

From vedlabs at gmail.com  Tue Sep 15 08:31:41 2009
From: vedlabs at gmail.com (Ved Labs)
Date: Tue, 15 Sep 2009 18:01:41 +0530
Subject: [c-nsp] debug bgp updates within VRF
Message-ID: <7db92dcc0909150531h149c3b34udd9272e24201d30a@mail.gmail.com>

How do i *debug bgp updates within VRF*
**
*Thanks,*
*Biddu.*

From amsoares at netcabo.pt  Tue Sep 15 08:56:57 2009
From: amsoares at netcabo.pt (Antonio Soares)
Date: Tue, 15 Sep 2009 13:56:57 +0100
Subject: [c-nsp] Cisco NAC - SSO Issues
Message-ID: <CDE6C38436CD443298626B22FECCBCE8@int.convex.pt>

Hello group,

I'm troubleshooting a NAC issue. I see lot's of CLOSE_WAIT sessions on the CAS and i need to find a way to restart the SSO service
(TCP:8910) without restarting the whole box. Disabling the option "Enable Agent-Based Windows Single Sign-On with Active Directory
(Kerberos)" in the CAM does not do the job. I think that after clearing these TCP stuck sessions, Single Sign-On will work again.


Thanks.

Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt



From jason at lixfeld.ca  Tue Sep 15 09:10:17 2009
From: jason at lixfeld.ca (Jason Lixfeld)
Date: Tue, 15 Sep 2009 09:10:17 -0400
Subject: [c-nsp] 12.2(18)SXD to 12.2(33)SRB|C|D
In-Reply-To: <200909151845.51812.mtinka@globaltransit.net>
References: <B32314DD-B600-40F0-A6EE-AD1D1A4736A5@lixfeld.ca>
	<20090914203953.GE51443@gerbil.cluepon.net>
	<200909151845.51812.mtinka@globaltransit.net>
Message-ID: <9CBBDD05-9C33-4108-9D0F-85255604AEE3@lixfeld.ca>

Upgraded to SRC4 last night and everything went pretty smoothly.

A couple things I'm wondering if anyone has seen with SRC4:

1-  When SRC4 booted, we were a little paniced when we saw that a  
bunch of our SFP ports were now dark.  We resolved it by pulling the  
fiber and the SFP and reseating each.  The original theory in doing  
that was to check to see if the SFP was genuine Cisco to see if we  
needed to enable service unsupported-transceiver but the side-effect  
was that it actually brought the port up.  We were able to get all our  
dark ports up this way before enabling transceiver support so we don't  
think it was related to that command (but enabled it for good measure).

2- We had to enable ip mtu 1500 on a few interfaces that had their  
port mtu cranked into jumbo range for OSPF to work.  Why we didn't  
have to do this in SXD is curious, but we are happy that SRC operates  
correctly (by showing us where our configs were inconsistent).

3- There is one device on the network (an ASR1002 running 2.4.0) that  
is unable to see the loopback address via OSPF from this 7600 we just  
upgraded.  It's built an adjacency with the 7600, so it's not an MTU  
thing, it just doesnt see the route for it's loopback interface.  We  
didn't do much digging into it last night because there was an  
alternate path on the ASR so we felt we could leave it till the AM,  
but strange indeed.  It may too be a misconfguration that SRC expects,  
which SXD was relaxed about but I  thought I'd ask anyway.

On 2009-09-15, at 6:45 AM, Mark Tinka <mtinka at globaltransit.net> wrote:

> On Tuesday 15 September 2009 04:39:53 am Richard A
> Steenbergen wrote:
>
>> Personally my recommendation for going forward is SRC
>> (SRC4 is pretty stable, all things considered).
>
> Would also recommend SRC; we have it largely deployed on a
> number of 7200's.
>
> SRC4 is stable, but a few issues, that will be resolved in
> SRC5, hound us. Nothing major, probably not faced by many
> others...
>
> Point is, SRC is probably a more mature release.
>
> Cheers,
>
> Mark.

From rodunn at cisco.com  Tue Sep 15 09:19:23 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Tue, 15 Sep 2009 09:19:23 -0400
Subject: [c-nsp] Cat 4948 NAT support
In-Reply-To: <20090914190205.GA57486@geeks.org>
References: <mailman.68.1251925701.2225.cisco-nsp@puck.nether.net>	<1AD3CD5F-2BBD-4B9A-88A0-F3A2D0166257@swingpad.com>
	<20090914190205.GA57486@geeks.org>
Message-ID: <4AAF945B.2040409@cisco.com>

The real issue with NAT today is ALG processing and scale.

My motto is if you are not going to sign up for full support in hardware 
on a box that can scale to 1+ Mpps don't bother half baking it.

I deal with a customer about once per week where they tried something 
like this.

The ASR1k (no I don't work for that BU) has it right. They do it all in 
the FP (translation setup, ALG, etc.) with no punts.

That's why the 6k doesn't scale even though it "inherited" NAT from the 
code base.

Rodney



Doug McIntyre wrote:
> On Mon, Sep 14, 2009 at 01:31:54PM -0400, Dan Benson wrote:
>> I have a 4948 that I was hoping to upgrade a few systems with but I am dead 
>> in the water as it seems it does not support NAT.
>>
>> According to the NAT matrix:
>>
>> http://supportwiki.cisco.com/ViewWiki/index.php/Network_Address_Translation_Catalyst_Switch_Support_Matrix
>>
>> This matrix seems very outdated so it would explain why the 4900 product 
>> line is not listed.
> 
> 
> If you notice, the *only* products listed there that supports it is
> the Cat6500.
> 
> The Cat 5k RSM was a seperate bolt-on router on a blade that slid into
> the chassis, and wasn't the switch engine at all. Anyway that stuff is
> old and dead (and was slow). 
> 
> So, don't go searching for switches that support NAT, the Cat6500 is it. 
> 
> Cisco leaves NAT to firewalls and routers, not switches. 
> 
> FWIW: The 4948 is still very current hardware. 
> 
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From amsoares at netcabo.pt  Tue Sep 15 10:19:51 2009
From: amsoares at netcabo.pt (Antonio Soares)
Date: Tue, 15 Sep 2009 15:19:51 +0100
Subject: [c-nsp] Cisco NAC - SSO Issues
In-Reply-To: <CDE6C38436CD443298626B22FECCBCE8@int.convex.pt>
References: <CDE6C38436CD443298626B22FECCBCE8@int.convex.pt>
Message-ID: <B058A2B326F2415CA09B54F831877F52@int.convex.pt>

I found a matching bug in the meanwhile but the workaround does not work:

+++++++++++++++++++++++++++++++++++++++++
CSCsk46672 Bug Details
CAS stops listening on 8910 after threads in CLOSE_WAIT state

Symptom:
Agent fails to perform ADSSO

Conditions:
CAS no longer listening to tcp port 8910 because 50 threads are already in CLOSE_WAIT state

Workaround:
Under Device Management > Clean Access Servers > CAS > Windows Auth
Click UPDATE on SSO service to flush the CLOSE_WAIT states
+++++++++++++++++++++++++++++++++++++++++ 

The box i'm troubleshooting is running release 4.0.5.


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Antonio Soares
Sent: ter?a-feira, 15 de Setembro de 2009 13:57
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Cisco NAC - SSO Issues

Hello group,

I'm troubleshooting a NAC issue. I see lot's of CLOSE_WAIT sessions on the CAS and i need to find a way to restart the SSO service
(TCP:8910) without restarting the whole box. Disabling the option "Enable Agent-Based Windows Single Sign-On with Active Directory
(Kerberos)" in the CAM does not do the job. I think that after clearing these TCP stuck sessions, Single Sign-On will work again.


Thanks.

Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



From luan at netcraftsmen.net  Tue Sep 15 10:53:48 2009
From: luan at netcraftsmen.net (Luan Nguyen)
Date: Tue, 15 Sep 2009 10:53:48 -0400
Subject: [c-nsp] Cisco NAC - SSO Issues
In-Reply-To: <B058A2B326F2415CA09B54F831877F52@int.convex.pt>
References: <CDE6C38436CD443298626B22FECCBCE8@int.convex.pt>
	<B058A2B326F2415CA09B54F831877F52@int.convex.pt>
Message-ID: <029301ca3614$54be8ba0$fe3ba2e0$@net>

I would suggest opening a TAC case.
Also, for NAC related problem, the CLEANACCESS at LISTSERV.MUOHIO.EDU would be
a better place to ask questions.

Regards,

--------------------------------------
Luan Nguyen
Chesapeake NetCraftsmen, LLC.
[Web] http://www.netcraftsmen.net
------------------------------------


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Antonio Soares
Sent: Tuesday, September 15, 2009 10:20 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Cisco NAC - SSO Issues

I found a matching bug in the meanwhile but the workaround does not work:

+++++++++++++++++++++++++++++++++++++++++
CSCsk46672 Bug Details
CAS stops listening on 8910 after threads in CLOSE_WAIT state

Symptom:
Agent fails to perform ADSSO

Conditions:
CAS no longer listening to tcp port 8910 because 50 threads are already in
CLOSE_WAIT state

Workaround:
Under Device Management > Clean Access Servers > CAS > Windows Auth
Click UPDATE on SSO service to flush the CLOSE_WAIT states
+++++++++++++++++++++++++++++++++++++++++ 

The box i'm troubleshooting is running release 4.0.5.


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Antonio Soares
Sent: ter?a-feira, 15 de Setembro de 2009 13:57
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Cisco NAC - SSO Issues

Hello group,

I'm troubleshooting a NAC issue. I see lot's of CLOSE_WAIT sessions on the
CAS and i need to find a way to restart the SSO service
(TCP:8910) without restarting the whole box. Disabling the option "Enable
Agent-Based Windows Single Sign-On with Active Directory
(Kerberos)" in the CAM does not do the job. I think that after clearing
these TCP stuck sessions, Single Sign-On will work again.


Thanks.

Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4426 (20090915) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4426 (20090915) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 


From amsoares at netcabo.pt  Tue Sep 15 12:04:01 2009
From: amsoares at netcabo.pt (Antonio Soares)
Date: Tue, 15 Sep 2009 17:04:01 +0100
Subject: [c-nsp] Cisco NAC - SSO Issues
In-Reply-To: <029301ca3614$54be8ba0$fe3ba2e0$@net>
References: <CDE6C38436CD443298626B22FECCBCE8@int.convex.pt>
	<B058A2B326F2415CA09B54F831877F52@int.convex.pt>
	<029301ca3614$54be8ba0$fe3ba2e0$@net>
Message-ID: <300215A427DE46AD80DC24FC3466C022@int.convex.pt>

Thanks for pointing me to the right place.

In the meanwhile, i can say that the workaround mentioned in the Bug release notes worked as expected. 50 stucked TCP sessions were
cleared what was enough to recover normal behavior. I still have 200+ in CLOSED_WAIT state but the next reboot will take care of
that :)


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

-----Original Message-----
From: Luan Nguyen [mailto:luan at netcraftsmen.net] 
Sent: ter?a-feira, 15 de Setembro de 2009 15:54
To: 'Antonio Soares'; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Cisco NAC - SSO Issues

I would suggest opening a TAC case.
Also, for NAC related problem, the CLEANACCESS at LISTSERV.MUOHIO.EDU would be a better place to ask questions.

Regards,

--------------------------------------
Luan Nguyen
Chesapeake NetCraftsmen, LLC.
[Web] http://www.netcraftsmen.net
------------------------------------


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Antonio Soares
Sent: Tuesday, September 15, 2009 10:20 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Cisco NAC - SSO Issues

I found a matching bug in the meanwhile but the workaround does not work:

+++++++++++++++++++++++++++++++++++++++++
CSCsk46672 Bug Details
CAS stops listening on 8910 after threads in CLOSE_WAIT state

Symptom:
Agent fails to perform ADSSO

Conditions:
CAS no longer listening to tcp port 8910 because 50 threads are already in CLOSE_WAIT state

Workaround:
Under Device Management > Clean Access Servers > CAS > Windows Auth Click UPDATE on SSO service to flush the CLOSE_WAIT states
+++++++++++++++++++++++++++++++++++++++++ 

The box i'm troubleshooting is running release 4.0.5.


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Antonio Soares
Sent: ter?a-feira, 15 de Setembro de 2009 13:57
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Cisco NAC - SSO Issues

Hello group,

I'm troubleshooting a NAC issue. I see lot's of CLOSE_WAIT sessions on the CAS and i need to find a way to restart the SSO service
(TCP:8910) without restarting the whole box. Disabling the option "Enable Agent-Based Windows Single Sign-On with Active Directory
(Kerberos)" in the CAM does not do the job. I think that after clearing these TCP stuck sessions, Single Sign-On will work again.


Thanks.

Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4426 (20090915) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


 

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4426 (20090915) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 



From linuxloader at gmail.com  Tue Sep 15 12:14:40 2009
From: linuxloader at gmail.com (Georgi Genov)
Date: Tue, 15 Sep 2009 19:14:40 +0300
Subject: [c-nsp] Cisco SCE 2020 and snmp  question
In-Reply-To: <4AAA5E97.7050106@gmail.com>
References: <4AAA5E97.7050106@gmail.com>
Message-ID: <4AAFBD70.6090409@gmail.com>

Donato Dunguihual Morales wrote:
> Hi,
>
> I need to graph via snmp and  mrtg or rrdttool , ip traffic and 
> protocols  for Cisco sce 2020 box.
>
> I saw in  the web , the utility rtmcmd.   
> http://www.cisco.com/en/US/products/ps6135/products_user_guide09186a00808165dd.html#o16507. 
>
>
> I?m  trying to  run the scripts, in a linux server, with all  
> requirements,  java , mrtg, rrdtool , but  i have the following error 
> . Does anyone have any experience with this script or another form for 
> generate a graph via snmp in SCE 2020?
>
>
>
> #  ./rtmcmd.sh -S "X.X.X:X" -U user -P ***** --pqb-sce=X.X.X.X 
> --source-dir=/templates --dest-dir=/rtm-output -c ./rtmcmd.cfg
> connecting to X.X.X.X ... done
> retrieving service configuration from SCE ... disconnecting from 
> device ... done
> Failed to retrieve service configuration from SCE X.X.X.X. Aborting!
>
>
>
> Thanks in advance
> Donato
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
That can be done easy with cacti , here is the post
http://forums.cacti.net/viewtopic.php?t=30931&start=0&postdays=0&postorder=asc&highlight= 


From justin at justinshore.com  Tue Sep 15 13:14:10 2009
From: justin at justinshore.com (Justin Shore)
Date: Tue, 15 Sep 2009 12:14:10 -0500
Subject: [c-nsp] SP-grade Ethernet over TDM
Message-ID: <4AAFCB62.9040005@justinshore.com>

Does anyone have any suggestions for providing Ethernet links over 
bonded T1s?

We originally looked at Overture.  They claimed that their product used 
standard MLPPP and interoped well with 7200s.  They sent out a tech to 
help configure it in a lab.  As it turns out they also require the use 
of BCP (Bridging Control Protocol).  To use BCP on a 7200 step #1 is to 
disable IP routing (literally, 'no ip routing').  That is required to 
facilitate bridging VLANs over MLPPP bundles.  Needless to say this 
wasn't an option since our router was doing more than just terminating 
EoTDM connections.  If we had an old 7200 sitting around we probably 
could have pulled it off.  Alternately, if we have a 7600 in that colo 
with DS3 SPAs we could have done the same thing without disabling 
routing.  I'm considering replacing that 7200 with an ASR in the future 
so perhaps this will become possible once again down the road, but not 
today.

I've also been looking at Adtran's Ethernet over TDM products.  It looks 
like you have to use their Total Access 5000 at the hub and then use 
their NetVanta 800 series as the CPE.  I don't know anything about the 
Total Access 5000 and can't access their documentation without an 
account (hard to sell the product when you won't let people access the 
docs beforehand).

Overture's CPEs for this application are the 140 and 180 models.  The 
price is right but the product just doesn't have a production SP-grade 
feel to it.  Management has to be done locally.  There isn't a CLI 
option which I would think would be a requirement for SPs wanting to 
either script changes or backup configurations.  It just doesn't feel 
production grade or SP-grade by any means.  It's not like their 2200 or 
5000 products which are much better.  I've always heard good things 
about Adtran and that they are Cisco-like but I've never actually used them.

What I'd like to find is a device that can bond multiple DS1s together 
with standards-based MLPPP and then bridge that to an Ethernet interface 
behind it.  I imagine that this would interop with our 7200s nicely.  It 
would be nice if there was some mechanism for in-line management as 
well, though I'm not sure how that would work short of pulling out a DS0 
for management access.  Does anyone know of such a product?  Does anyone 
know of any other ways of accomplishing that same or similar thing?  I 
don't know of any cisco products that can do this.  I could foresee a 
situation where I need multiple VLANs at the customer premise so the 
Adtran solution would likely fit in better with this potential need.

Thanks
  Justin


From zeusdadog at gmail.com  Tue Sep 15 13:21:00 2009
From: zeusdadog at gmail.com (Jay Nakamura)
Date: Tue, 15 Sep 2009 13:21:00 -0400
Subject: [c-nsp] AnyConnect VPN client, IOS, and Vista
Message-ID: <9418aca70909151021q6cb2441cwec96c1694d29e138@mail.gmail.com>

Has anyone gotten AnyConnect client to work with IOS router and Vista?
 (With self signed cert?)

I got it to work with XP but not Vista.  Can someone share their
config or some pointers?

With Vista, it gets to the cert warning part, then dies.

aaa authentication login ciscocp_vpn_xauth_ml_1 group radius
crypto pki trustpoint someVPN
 enrollment selfsigned
 serial-number none
 ip-address none
 subject-name CN=vpn, O=somedomain.com, ST=IN, C=US
 revocation-check crl
 rsakeypair someVPN_RSAKey 1024
!
!
crypto pki certificate chain FirstCapitalVPN
 certificate self-signed 01
<SNIP>
        quit
!
!
interface FastEthernet0/0
 ip address w.x.y.z 255.255.255.240
 ip nat outside
!
interface FastEthernet0/1
 ip address 10.0.0.254 255.255.255.0
 ip nat inside
!
ip local pool VPNPOOL 192.168.100.1 192.168.100.254
ip route 0.0.0.0 0.0.0.0 w.x.y.z1
!
radius-server host 10.0.0.26 auth-port 1645 acct-port 1646 key 7
03051418135F724216051C171C005F180C333970
!
webvpn gateway gateway_1
 ip address w.x.y.z port 443
 http-redirect port 80
 ssl trustpoint someVPN
 inservice
 !
webvpn install svc flash:/webvpn/anyconnect-win-2.3.2016-k9.pkg sequence 1
 !
webvpn install svc
flash:/webvpn/anyconnect-macosx-i386-2.3.2016-k9.pkg sequence 2
 !
webvpn install svc
flash:/webvpn/anyconnect-macosx-powerpc-2.3.2016-k9.pkg sequence 3
 !
webvpn install svc
flash:/webvpn/anyconnect-wince-ARMv4I-2.3.2016-k9.pkg sequence 4
 !
webvpn context webvpn
 secondary-color white
 title-color #669999
 text-color black
 ssl authenticate verify all
 !
 !
 policy group policy_1
   functions svc-enabled
   svc address-pool "VPNPOOL"
   svc default-domain "somedomain.com"
   svc keep-client-installed
   svc split dns "somedomain.com"
   svc split include 10.0.0.0 255.255.255.0
   svc dns-server primary 10.0.0.26
   svc dns-server secondary 10.0.0.6
   svc wins-server primary 10.0.0.26
   svc wins-server secondary 10.0.0.6
 default-group-policy policy_1
 aaa authentication list ciscocp_vpn_xauth_ml_1
 gateway gateway_1
 inservice
!
end

From rdobbins at arbor.net  Tue Sep 15 13:31:57 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Wed, 16 Sep 2009 00:31:57 +0700
Subject: [c-nsp] SP-grade Ethernet over TDM
In-Reply-To: <4AAFCB62.9040005@justinshore.com>
References: <4AAFCB62.9040005@justinshore.com>
Message-ID: <11CC866C-A198-4BDD-AB2E-0CE16F363760@arbor.net>


On Sep 16, 2009, at 12:14 AM, Justin Shore wrote:

> Does anyone have any suggestions for providing Ethernet links over  
> bonded T1s?


Yes - don't do it, given that the basic premise of running layer-2  
between sites is a Very Bad Idea, much less trying to do it over  
bonded T1s, heh.

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

Sorry, sometimes I mistake your existential crises for technical
insights.

			-- xkcd #625


From jay at west.net  Tue Sep 15 13:39:05 2009
From: jay at west.net (Jay Hennigan)
Date: Tue, 15 Sep 2009 10:39:05 -0700
Subject: [c-nsp] "Enhanced" download procedure
Message-ID: <4AAFD139.4050402@west.net>

What the #$^&$@# is going on with Cisco's download site?  It completely 
hangs Firefox with some shopping cart java thing.  And this is downright 
scary:  http://www.west.net/~jay/images/cisco-wants-root.png

Enhanced downloads, brought to you by the same people who brought us 
enhanced interrogation?

Is there a workaround?  What happened to our friend kobayashi ?

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

From cisco at peakpeak.com  Tue Sep 15 13:51:04 2009
From: cisco at peakpeak.com (cisco)
Date: Tue, 15 Sep 2009 11:51:04 -0600
Subject: [c-nsp] Cisco 2600 and ISDN
Message-ID: <C6D53028.4A2E%cisco@peakpeak.com>

I called the TAC but they won't help with this because they say they don't
support 2600's.

I have a central side 2600 with an ISDN BRI card in it, and a remote site
with a 2600 and ISDN BRI card in it.  I have the ISDN lines working, and I
have the remote site calling into the central site (I can see the calls on
the console) and RADIUS appears to be authenticating the call.  Then the
session drops with this:

Tue Sep 15 11:09:38 2009: DEBUG: Packet dump:
*** Received from port 1646 ....
Code:       Accounting-Request
Identifier: 72
Attributes:
    NAS-IP-Address = x.x.x.x
    NAS-Port = 30001
    NAS-Port-Type = ISDN
    User-Name = "theuser"
    Called-Station-Id = "xxxxxxx"
    Calling-Station-Id = "xxxxxxxxxx"
    Acct-Status-Type = Stop
    Acct-Authentic = RADIUS
    Service-Type = Framed-User
    Acct-Session-Id = "000005EF"
    Framed-Protocol = PPP
    Ascend-Disconnect-Cause = pppCloseEvent
    Ascend-Pre-Input-Octets = 90
    Ascend-Pre-Output-Octets = 73
    Ascend-Pre-Input-Packets = 3
    Ascend-Pre-Output-Packets = 3
    Acct-Input-Octets = 0
    Acct-Output-Octets = 8
    Acct-Input-Packets = 0
    Acct-Output-Packets = 1
    Ascend-PreSession-Time = 0
    Acct-Session-Time = 1
    Ascend-Data-Rate = 64000
    Ascend-Xmit-Rate = 64000
    Acct-Delay-Time = 0

Can anyone detect any inconsistencies in the 2 router's configs below?

Thanks,
CJ


Here is the config snippet of the central site:

aaa new-model
aaa authentication login default group radius local
aaa authentication login vtylocal local
aaa authentication login console none
aaa authentication ppp default group radius
aaa authorization exec default local group radius
aaa authorization exec console none
aaa authorization network default group radius
aaa accounting update newinfo
aaa accounting exec default start-stop group radius
aaa accounting network default start-stop group radius
!
isdn switch-type basic-ni
!
interface Multilink1
 ip address negotiated
 no ip route-cache cef
 no cdp enable
 ppp authentication pap
 ppp multilink
multilink-group 1
!
interface BRI0/0
 description ISDN Connection
 ip address negotiated
 encapsulation ppp
 load-interval 30
 no keepalive
 dialer pool-member 1
 isdn switch-type basic-ni
 isdn spid1 xxxxxxxxxx1111 xxxxxxx
 isdn spid2 xxxxxxxxxx1111 xxxxxxx
 ppp authentication pap
 ppp multilink
!
interface Dialer0
 ip address negotiated
 encapsulation ppp
 dialer in-band
 dialer idle-timeout 3600
 dialer-group 1
 no cdp enable
 ppp authentication pap
 ppp multilink

Here is the config snippet of the remote site:

aaa authentication login userauthen local
aaa authorization network groupauthor local
aaa session-id common
!
isdn switch-type basic-ni
!
interface BRI0/1
 no ip address
 no ip directed-broadcast
 encapsulation ppp
 no keepalive
 dialer rotary-group 0
 isdn switch-type basic-ni
 isdn spid2 xxxxxxxxxx1111 xxxxxxx
 isdn spid1 xxxxxxxxxx1111 xxxxxxx
 isdn incoming-voice modem
 no cdp enable
! 
interface Dialer0
 ip address negotiated
 no ip directed-broadcast
 ip nat outside
 encapsulation ppp
 dialer in-band
 dialer idle-timeout 3600
 dialer string xxxxxxxxxx
 dialer-group 1
 no cdp enable
 ppp authentication pap callin
 ppp pap sent-username theuser@ password 0 thepassword
 ppp multilink

Here is some exciting debug output:

21:50:96657194476: ISDN BR0/0: received HOST_DISCONNECT_ACK call_id 0x93F
21:50:96657194396: ISDN BR0/0: HOST_DISCONNECT_ACK: call type is DATA
21:50:94489280523: %LINK-3-UPDOWN: Interface BRI0/0:2, changed state to down
21:50:96657194324: BR0/0:2 LCP: State is Closed
21:50:96657194284: BR0/0:2 PPP: Phase is DOWN
21:50:98784247808: ISDN BR0/0: Incoming call id = 0x940, dsl 0
21:50:98784247808: ISDN BR0/0: received HOST_INCOMING_CALL call_id 0x940
21:50:98784247808: ISDN BR0/0: HOST_INCOMING_CALL: voice_answer_data = FALSE
21:50:98784248491: ISDN BR0/0: RM returned call_type 0 resource type 0
21:50:23: ISDN BR0/0: isdn_send_connect(): msg 4, call id 0x940, ces 1 bchan
0, call type DATA
21:50:23: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up
21:50:23: BR0/0:1 PPP: Treating connection as a callin
21:50:23: BR0/0:1 PPP: Phase is ESTABLISHING, Passive Open
21:50:23: BR0/0:1 LCP: State is Listen
21:50:98784247808: ISDN BR0/0: received HOST_CONNECT call_id 0x940
21:50:98784247808: ISDN BR0/0: Event: Connected to xxxxxxxxxx on B1 at 64
Kb/s
21:50:24: BR0/0:1 LCP: I CONFREQ [Listen] id 38 len 29
21:50:24: BR0/0:1 LCP:    MagicNumber 0x0A4277A7 (0x05060A4277A7)
21:50:24: BR0/0:1 LCP:    MRRU 1524 (0x110405F4)
21:50:24: BR0/0:1 LCP:    EndpointDisc 1 Local
(0x130F016C6D64696E74657265737473)
21:50:24: BR0/0:1 LCP: O CONFREQ [Listen] id 89 len 29
21:50:24: BR0/0:1 LCP:    AuthProto PAP (0x0304C023)
21:50:24: BR0/0:1 LCP:    MagicNumber 0xD50821E9 (0x0506D50821E9)
21:50:24: BR0/0:1 LCP:    MRRU 1524 (0x110405F4)
21:50:24: BR0/0:1 LCP:    EndpointDisc 1 Local (0x130B0174656D706973646E)
21:50:24: BR0/0:1 LCP: O CONFACK [Listen] id 38 len 29
21:50:24: BR0/0:1 LCP:    MagicNumber 0x0A4277A7 (0x05060A4277A7)
21:50:24: BR0/0:1 LCP:    MRRU 1524 (0x110405F4)
21:50:24: BR0/0:1 LCP:    EndpointDisc 1 Local
(0x130F016C6D64696E74657265737473)
21:50:24: BR0/0:1 LCP: I CONFACK [ACKsent] id 89 len 29
21:50:24: BR0/0:1 LCP:    AuthProto PAP (0x0304C023)
21:50:24: BR0/0:1 LCP:    MagicNumber 0xD50821E9 (0x0506D50821E9)
21:50:24: BR0/0:1 LCP:    MRRU 1524 (0x110405F4)
21:50:24: BR0/0:1 LCP:    EndpointDisc 1 Local (0x130B0174656D706973646E)
21:50:24: BR0/0:1 LCP: State is Open
21:50:24: BR0/0:1 PPP: Phase is AUTHENTICATING, by this end
21:50:24: BR0/0:1 PAP: I AUTH-REQ id 139 len 19 from "theuser"
21:50:24: BR0/0:1 PAP: Authenticating peer theuser
21:50:24: BR0/0:1 PAP: O AUTH-ACK id 139 len 5
21:50:24: BR0/0:1 PPP: Phase is VIRTUALIZED
21:50:24: ISDN BR0/0: Event: Hangup call to call id 0x940  ces = 1
21:50:24: ISDN BR0/0: process_disconnect(): call id 0x940, call type is
DATA, b_idb 0x815BB4DC, ces 1, cause 0x10



From sthaug at nethelp.no  Tue Sep 15 13:52:01 2009
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Tue, 15 Sep 2009 19:52:01 +0200 (CEST)
Subject: [c-nsp] SP-grade Ethernet over TDM
In-Reply-To: <11CC866C-A198-4BDD-AB2E-0CE16F363760@arbor.net>
References: <4AAFCB62.9040005@justinshore.com>
	<11CC866C-A198-4BDD-AB2E-0CE16F363760@arbor.net>
Message-ID: <20090915.195201.74746905.sthaug@nethelp.no>

> > Does anyone have any suggestions for providing Ethernet links over  
> > bonded T1s?
> 
> 
> Yes - don't do it, given that the basic premise of running layer-2  
> between sites is a Very Bad Idea, much less trying to do it over  
> bonded T1s, heh.

In general I would agree. However, there is quite a bit of experience
with Ethernet over bonded SHDSL lines. And it works quite well. See
for instance

       http://www.zhone.com/products/ETHX-3300/

I would be rather surprised if Ethernet over bonded T1s performed
significantly worse...

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From achatz at forthnet.gr  Tue Sep 15 14:02:33 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Tue, 15 Sep 2009 21:02:33 +0300
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AAFD139.4050402@west.net>
References: <4AAFD139.4050402@west.net>
Message-ID: <4AAFD6B9.4050903@forthnet.gr>

It should work after you allow it.

Btw, it took me 1 hour to download an ASR1k IOS today with the new downloader!!!
And i couldn't find another way to download it.

-- 
Tassos

Jay Hennigan wrote on 15/09/2009 20:39:
> What the #$^&$@# is going on with Cisco's download site?  It completely 
> hangs Firefox with some shopping cart java thing.  And this is downright 
> scary:  http://www.west.net/~jay/images/cisco-wants-root.png
> 
> Enhanced downloads, brought to you by the same people who brought us 
> enhanced interrogation?
> 
> Is there a workaround?  What happened to our friend kobayashi ?
> 
> -- 
> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
> Impulse Internet Service  -  http://www.impulse.net/
> Your local telephone and internet company - 805 884-6323 - WB6RDV
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From jay at west.net  Tue Sep 15 14:09:06 2009
From: jay at west.net (Jay Hennigan)
Date: Tue, 15 Sep 2009 11:09:06 -0700
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AAFD6B9.4050903@forthnet.gr>
References: <4AAFD139.4050402@west.net> <4AAFD6B9.4050903@forthnet.gr>
Message-ID: <4AAFD842.6030801@west.net>

Tassos Chatzithomaoglou wrote:
> It should work after you allow it.

Why should I need to allow "Unrestricted access" to my computer in order 
to download a file?  What exactly is that Java applet doing?  Could it 
do something malicious?  How do you know for sure?

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

From cchurc05 at harris.com  Tue Sep 15 14:19:04 2009
From: cchurc05 at harris.com (Church, Charles)
Date: Tue, 15 Sep 2009 14:19:04 -0400
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AAFD842.6030801@west.net>
References: <4AAFD139.4050402@west.net> <4AAFD6B9.4050903@forthnet.gr>
	<4AAFD842.6030801@west.net>
Message-ID: <290EF89F13F04F4E924BB235A46D18F19B1A43@MLBMXUS2.cs.myharris.net>

It looks like it needs unrestricted access so that it can access your file system, since it presents its own file manager looking thing so you can pick where to save the files.  No way to know for sure though.

Chuck

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jay Hennigan
Sent: Tuesday, September 15, 2009 2:09 PM
To: Cisco Mailing list
Subject: Re: [c-nsp] "Enhanced" download procedure


Tassos Chatzithomaoglou wrote:
> It should work after you allow it.

Why should I need to allow "Unrestricted access" to my computer in order 
to download a file?  What exactly is that Java applet doing?  Could it 
do something malicious?  How do you know for sure?

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From sethm at rollernet.us  Tue Sep 15 14:22:16 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 15 Sep 2009 11:22:16 -0700
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AAFD842.6030801@west.net>
References: <4AAFD139.4050402@west.net> <4AAFD6B9.4050903@forthnet.gr>
	<4AAFD842.6030801@west.net>
Message-ID: <4AAFDB58.4040204@rollernet.us>

Jay Hennigan wrote:
> Tassos Chatzithomaoglou wrote:
>> It should work after you allow it.
> 
> Why should I need to allow "Unrestricted access" to my computer in order
> to download a file?  What exactly is that Java applet doing?  Could it
> do something malicious?  How do you know for sure?
> 

I can't even get that far. The stupid thing just says "This image has
already been added to cart" right along with "0 items".

Thanks Cisco for being dipsh*ts.

~Seth

From jared at puck.nether.net  Tue Sep 15 14:23:50 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 15 Sep 2009 14:23:50 -0400
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <290EF89F13F04F4E924BB235A46D18F19B1A43@MLBMXUS2.cs.myharris.net>
References: <4AAFD139.4050402@west.net> <4AAFD6B9.4050903@forthnet.gr>
	<4AAFD842.6030801@west.net>
	<290EF89F13F04F4E924BB235A46D18F19B1A43@MLBMXUS2.cs.myharris.net>
Message-ID: <97DE6B69-D0E2-425D-9F0D-49D0BBED3AF3@puck.nether.net>


On Sep 15, 2009, at 2:19 PM, Church, Charles wrote:

> It looks like it needs unrestricted access so that it can access  
> your file system, since it presents its own file manager looking  
> thing so you can pick where to save the files.  No way to know for  
> sure though.


Another reason to use LYNX to download software.

- Jared

From jay at west.net  Tue Sep 15 14:25:29 2009
From: jay at west.net (Jay Hennigan)
Date: Tue, 15 Sep 2009 11:25:29 -0700
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <290EF89F13F04F4E924BB235A46D18F19B1A43@MLBMXUS2.cs.myharris.net>
References: <4AAFD139.4050402@west.net> <4AAFD6B9.4050903@forthnet.gr>
	<4AAFD842.6030801@west.net>
	<290EF89F13F04F4E924BB235A46D18F19B1A43@MLBMXUS2.cs.myharris.net>
Message-ID: <4AAFDC19.3070908@west.net>

Church, Charles wrote:
> It looks like it needs unrestricted access so that it can access your file system, since it presents its own file manager looking thing so you can pick where to save the files.  No way to know for sure though.

But every browser has a built-in download utility so this is worthless 
complexity and a potential security hole.  It also completely breaks 
lynx and wget, and the benefits are exactly what?

Do the people at Cisco have any idea that this so-called improvement is 
actually a hindrance?

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

From mksmith at adhost.com  Tue Sep 15 14:35:15 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Tue, 15 Sep 2009 11:35:15 -0700
Subject: [c-nsp] SP-grade Ethernet over TDM
In-Reply-To: <4AAFCB62.9040005@justinshore.com>
References: <4AAFCB62.9040005@justinshore.com>
Message-ID: <17838240D9A5544AAA5FF95F8D52031606AFC91B@ad-exh01.adhost.lan>

Top posting since it's so brief.

http://www.radware.com -> they have all different manner of conversion
technologies in their product set.

Mike

--
Michael K. Smith - CISSP, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Justin Shore
> Sent: Tuesday, September 15, 2009 10:14 AM
> To: 'Cisco-nsp'
> Subject: [c-nsp] SP-grade Ethernet over TDM
> 
> Does anyone have any suggestions for providing Ethernet links over
> bonded T1s?
> 
> We originally looked at Overture.  They claimed that their product
used
> standard MLPPP and interoped well with 7200s.  They sent out a tech to
> help configure it in a lab.  As it turns out they also require the use
> of BCP (Bridging Control Protocol).  To use BCP on a 7200 step #1 is
to
> disable IP routing (literally, 'no ip routing').  That is required to
> facilitate bridging VLANs over MLPPP bundles.  Needless to say this
> wasn't an option since our router was doing more than just terminating
> EoTDM connections.  If we had an old 7200 sitting around we probably
> could have pulled it off.  Alternately, if we have a 7600 in that colo
> with DS3 SPAs we could have done the same thing without disabling
> routing.  I'm considering replacing that 7200 with an ASR in the
future
> so perhaps this will become possible once again down the road, but not
> today.
> 
> I've also been looking at Adtran's Ethernet over TDM products.  It
> looks
> like you have to use their Total Access 5000 at the hub and then use
> their NetVanta 800 series as the CPE.  I don't know anything about the
> Total Access 5000 and can't access their documentation without an
> account (hard to sell the product when you won't let people access the
> docs beforehand).
> 
> Overture's CPEs for this application are the 140 and 180 models.  The
> price is right but the product just doesn't have a production SP-grade
> feel to it.  Management has to be done locally.  There isn't a CLI
> option which I would think would be a requirement for SPs wanting to
> either script changes or backup configurations.  It just doesn't feel
> production grade or SP-grade by any means.  It's not like their 2200
or
> 5000 products which are much better.  I've always heard good things
> about Adtran and that they are Cisco-like but I've never actually used
> them.
> 
> What I'd like to find is a device that can bond multiple DS1s together
> with standards-based MLPPP and then bridge that to an Ethernet
> interface
> behind it.  I imagine that this would interop with our 7200s nicely.
> It
> would be nice if there was some mechanism for in-line management as
> well, though I'm not sure how that would work short of pulling out a
> DS0
> for management access.  Does anyone know of such a product?  Does
> anyone
> know of any other ways of accomplishing that same or similar thing?  I
> don't know of any cisco products that can do this.  I could foresee a
> situation where I need multiple VLANs at the customer premise so the
> Adtran solution would likely fit in better with this potential need.
> 
> Thanks
>   Justin
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From jared at puck.nether.net  Tue Sep 15 14:39:06 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 15 Sep 2009 14:39:06 -0400
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AAFDB58.4040204@rollernet.us>
References: <4AAFD139.4050402@west.net> <4AAFD6B9.4050903@forthnet.gr>
	<4AAFD842.6030801@west.net> <4AAFDB58.4040204@rollernet.us>
Message-ID: <F62B968F-7B45-449D-B79C-07FFD774E1B2@puck.nether.net>


On Sep 15, 2009, at 2:22 PM, Seth Mattinen wrote:

> Jay Hennigan wrote:
>> Tassos Chatzithomaoglou wrote:
>>> It should work after you allow it.
>>
>> Why should I need to allow "Unrestricted access" to my computer in  
>> order
>> to download a file?  What exactly is that Java applet doing?  Could  
>> it
>> do something malicious?  How do you know for sure?
>>
>
> I can't even get that far. The stupid thing just says "This image has
> already been added to cart" right along with "0 items".
>
> Thanks Cisco for being dipsh*ts.


https://puck.nether.net/pipermail/cisco-nsp/2009-August/063367.html
https://puck.nether.net/pipermail/cisco-nsp/2009-August/063276.html
https://puck.nether.net/pipermail/cisco-nsp/2009-August/063209.html

	Go ahead and nag these folks, They asked for it.

	- Jared

From jared at puck.nether.net  Tue Sep 15 14:41:29 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 15 Sep 2009 14:41:29 -0400
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AAFDC19.3070908@west.net>
References: <4AAFD139.4050402@west.net> <4AAFD6B9.4050903@forthnet.gr>
	<4AAFD842.6030801@west.net>
	<290EF89F13F04F4E924BB235A46D18F19B1A43@MLBMXUS2.cs.myharris.net>
	<4AAFDC19.3070908@west.net>
Message-ID: <F8583D78-8AA3-45C9-8FD2-4727A3C03F46@puck.nether.net>


On Sep 15, 2009, at 2:25 PM, Jay Hennigan wrote:

> Church, Charles wrote:
>> It looks like it needs unrestricted access so that it can access  
>> your file system, since it presents its own file manager looking  
>> thing so you can pick where to save the files.  No way to know for  
>> sure though.
>
> But every browser has a built-in download utility so this is  
> worthless complexity and a potential security hole.  It also  
> completely breaks lynx and wget, and the benefits are exactly what?
>
> Do the people at Cisco have any idea that this so-called improvement  
> is actually a hindrance?

No.

They don't care.

Just like this person, but at least this was a joke:

http://snltranscripts.jt.org/76/76aphonecompany.phtml

	- Jared


From rodunn at cisco.com  Tue Sep 15 14:42:36 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Tue, 15 Sep 2009 14:42:36 -0400
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AAFDB58.4040204@rollernet.us>
References: <4AAFD139.4050402@west.net>
	<4AAFD6B9.4050903@forthnet.gr>	<4AAFD842.6030801@west.net>
	<4AAFDB58.4040204@rollernet.us>
Message-ID: <4AAFE01C.3080602@cisco.com>

Please check the email thread a week or so back where I gave the direct 
contacts for feedback.

They are open and want to hear helpful constructive feedback.

Rodney



Seth Mattinen wrote:
> Jay Hennigan wrote:
>> Tassos Chatzithomaoglou wrote:
>>> It should work after you allow it.
>> Why should I need to allow "Unrestricted access" to my computer in order
>> to download a file?  What exactly is that Java applet doing?  Could it
>> do something malicious?  How do you know for sure?
>>
> 
> I can't even get that far. The stupid thing just says "This image has
> already been added to cart" right along with "0 items".
> 
> Thanks Cisco for being dipsh*ts.
> 
> ~Seth
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From achatz at forthnet.gr  Tue Sep 15 14:48:16 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Tue, 15 Sep 2009 21:48:16 +0300
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AAFDB58.4040204@rollernet.us>
References: <4AAFD139.4050402@west.net>
	<4AAFD6B9.4050903@forthnet.gr>	<4AAFD842.6030801@west.net>
	<4AAFDB58.4040204@rollernet.us>
Message-ID: <4AAFE170.6070307@forthnet.gr>

You probably need to enabled cookies.

-- 
Tassos


Seth Mattinen wrote on 15/09/2009 21:22:
> Jay Hennigan wrote:
>> Tassos Chatzithomaoglou wrote:
>>> It should work after you allow it.
>> Why should I need to allow "Unrestricted access" to my computer in order
>> to download a file?  What exactly is that Java applet doing?  Could it
>> do something malicious?  How do you know for sure?
>>
> 
> I can't even get that far. The stupid thing just says "This image has
> already been added to cart" right along with "0 items".
> 
> Thanks Cisco for being dipsh*ts.
> 
> ~Seth
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 

From sethm at rollernet.us  Tue Sep 15 14:56:19 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 15 Sep 2009 11:56:19 -0700
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <97DE6B69-D0E2-425D-9F0D-49D0BBED3AF3@puck.nether.net>
References: <4AAFD139.4050402@west.net>
	<4AAFD6B9.4050903@forthnet.gr>	<4AAFD842.6030801@west.net>	<290EF89F13F04F4E924BB235A46D18F19B1A43@MLBMXUS2.cs.myharris.net>
	<97DE6B69-D0E2-425D-9F0D-49D0BBED3AF3@puck.nether.net>
Message-ID: <4AAFE353.8030808@rollernet.us>

Jared Mauch wrote:
> 
> On Sep 15, 2009, at 2:19 PM, Church, Charles wrote:
> 
>> It looks like it needs unrestricted access so that it can access your
>> file system, since it presents its own file manager looking thing so
>> you can pick where to save the files.  No way to know for sure though.
> 
> 
> Another reason to use LYNX to download software.
> 

Is that even possible anymore with the changes they've made?

~Seth

From yanf787 at yahoo.com  Tue Sep 15 15:16:49 2009
From: yanf787 at yahoo.com (Yan Filyurin)
Date: Tue, 15 Sep 2009 12:16:49 -0700 (PDT)
Subject: [c-nsp] MPLS TE Fast Re-route
In-Reply-To: <7EA99F102607DF43BDF25CC68475008703DDDE35@lhmail.btinet.local>
References: <7EA99F102607DF43BDF25CC68475008703DDDE35@lhmail.btinet.local>
Message-ID: <584698.83741.qm@web58703.mail.re1.yahoo.com>

When you say backup path for patch-protection, are you talking about path protection?  I've never done path protection, but it is slightly slower than FRR with link or node protection to converge, but  from what I understand it is alternative to FRR that does link and node and the path gets set up in advance, so bandwidth has to be reserved, but then again you don't have to reserve too much bandwidth, as the path is backup and its reservation should not interfere in the rservation of other primary paths. 

As far as MPLS link and node and protection where FRR comes in, same thing happens.  The path gets set up in advance and you can protect multiple links with one backup path in case of link and node protection and if you do MPLS TE mesh groups (of which I only read about and see in the lab) you can have relatively easy configuration, but possibly too much troubleshooting.  So, the path is set up in advance and you can either set this up to protect until the primary tunnel fixes itself through another path, or in some cases when you don't want it happen you can keep it going on the backup path until the primary tunnel fixes itself by another path going back up.  So to answer your question, the path is built, and "show mpls tra fa da" (too lazy to type it up) should show you the info for the backup path.  At least that is how I remember it, os the path is built and ready for failure. 

But I think you know all that anyway.  I've only read about this, but there is a concept of using backup tunnel bandwidth protection where you can say how much bandwidth of all primary tunnels it is protecting can go on it. OPNET if you have access to it (and it is too expensive for most people to use it) is good about calculating just how to best plan for various outages and what happens when various outages in a TE environment happen. 

Yan




________________________________
From: Charlie Greenaway <Charlie.Greenaway at btinet.bt.com>
To: cisco-nsp at puck.nether.net
Sent: Monday, September 14, 2009 7:25:36 PM
Subject: [c-nsp] MPLS TE Fast Re-route

Hi,

I have a question on MPLS TE and Fast Re-Route.

I have a test network and I want to check that the behaviour I am seeing is correct.

When you set-up an backup path for patch-protection, it would seem that RSVP sends signalling messages down the backup path to reserve the bandwidth.  However, it does not seem to build an LSP and assign labels to it until the primary path breaks.  Is this correct?  Has anyone got any advice on using MPLS FRR?

Thanks,

Charlie G



Charlie Greenaway - CCIE#11226 (Security/R&S)

Solutions Architect | BT iNet | 
Email: charlie.greenaway at btinet.bt.com | Web: www.btinet.bt.com 



This electronic message contains information from BT iNet, which may be privileged or confidential.  The information is intended for use only by the individual(s) or entity named above.  If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is strictly prohibited.  If you have received this e-mail in error, please let me know immediately on the e-mail address above. 
Activity and use of the BT iNet e-mail system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



      

From colin at netech.ie  Tue Sep 15 16:28:35 2009
From: colin at netech.ie (Colin Whittaker)
Date: Tue, 15 Sep 2009 21:28:35 +0100
Subject: [c-nsp] LLDP between a 6500 and a 3750
Message-ID: <20090915202835.GA972@infiltrator.stdlib.net>

Having a wierd issue with LLDP between a 6500 and a 3750
There are two gig links which are in a port channel.
The 6500 (r2 below) sees a lldp neighbor on both ports but the 3750 only
shows the 6500 being a neighbor on the port which it has most recently
received an update. This is breaking some of our automated tests to make
sure switches have been correctly cabled which we are trying to make
more multivendor capable. 

Has anyone seen anything like this before.

r2#sh lldp neighbors

Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID           Local Intf     Hold-time  Capability      Port ID
acc-sw              Gi3/9          120                        Gi2/0/1
acc-sw              Gi3/10         120                        Gi2/0/2

acc-sw#sh lldp neighbors

Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID           Local Intf     Hold-time  Capability      Port ID
r2      	    Gi2/0/1        60         R               desc

Total entries displayed: 2

acc-sw#sh lldp neighbors

Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID           Local Intf     Hold-time  Capability      Port ID
r2                  Gi2/0/2        60         R               desc


-- 
Colin Whittaker					+353 (0)86 8211 965
http://colin.netech.ie			            colin at netech.ie

From judah.scott.iam at gmail.com  Tue Sep 15 16:53:24 2009
From: judah.scott.iam at gmail.com (Judah Scott)
Date: Tue, 15 Sep 2009 13:53:24 -0700
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AAFE353.8030808@rollernet.us>
References: <4AAFD139.4050402@west.net> <4AAFD6B9.4050903@forthnet.gr>
	<4AAFD842.6030801@west.net>
	<290EF89F13F04F4E924BB235A46D18F19B1A43@MLBMXUS2.cs.myharris.net>
	<97DE6B69-D0E2-425D-9F0D-49D0BBED3AF3@puck.nether.net>
	<4AAFE353.8030808@rollernet.us>
Message-ID: <3172b9cb0909151353l2a799961x6af769c5f68eb556@mail.gmail.com>

I agree 100%  It makes no sense to force people to use proprietary download
managers, especially when they fund the bandwidth used to retrieve the
file.  :thumbdown:



On Tue, Sep 15, 2009 at 11:56 AM, Seth Mattinen <sethm at rollernet.us> wrote:

> Jared Mauch wrote:
> >
> > On Sep 15, 2009, at 2:19 PM, Church, Charles wrote:
> >
> >> It looks like it needs unrestricted access so that it can access your
> >> file system, since it presents its own file manager looking thing so
> >> you can pick where to save the files.  No way to know for sure though.
> >
> >
> > Another reason to use LYNX to download software.
> >
>
> Is that even possible anymore with the changes they've made?
>
> ~Seth
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From dave at brockmans.com  Tue Sep 15 17:26:36 2009
From: dave at brockmans.com (Dave Brockman)
Date: Tue, 15 Sep 2009 17:26:36 -0400
Subject: [c-nsp] ASA5505, Restricted VLAN & VPN
Message-ID: <4AB0068C.5040708@brockmans.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all, first time poster, please be gentle...

I have a client scenario that I can't work out in the lab for a few
days, hoping someone here might already know if it is possible or not.

I have a client with an ASA5505, base license, currently utilizing the
"restricted" VLAN to provide access to the internet only, across the
"outside" interface.  Is it possible to make a VPN connection from the
restricted VLAN via (I assume) the "outside" interface, and gain
connectivity to the "inside" interface across said VPN?  I've been able
to do similar things with IOS routers in the past, I just can't nail
down from the documentation if this would be allowed on an ASA utilizing
the included restricted VLAN.  Thanks in advance for any insight.

Regards,

dtb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqwBooACgkQABP1RO+tr2TqhgCdG+/SrXMPEAhy6uoMJ9ymfK/2
tYMAn2dNigfolVLSWr/s6Nqc2ZW7v0pB
=7sES
-----END PGP SIGNATURE-----

From mksmith at adhost.com  Tue Sep 15 18:41:53 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Tue, 15 Sep 2009 15:41:53 -0700
Subject: [c-nsp] ASA5505, Restricted VLAN & VPN
In-Reply-To: <4AB0068C.5040708@brockmans.com>
References: <4AB0068C.5040708@brockmans.com>
Message-ID: <17838240D9A5544AAA5FF95F8D52031606AFC9C5@ad-exh01.adhost.lan>

Hello Dave:

<snip>
> Hello all, first time poster, please be gentle...
> 
> I have a client scenario that I can't work out in the lab for a few
> days, hoping someone here might already know if it is possible or not.
> 
> I have a client with an ASA5505, base license, currently utilizing the
> "restricted" VLAN to provide access to the internet only, across the
> "outside" interface.  Is it possible to make a VPN connection from the
> restricted VLAN via (I assume) the "outside" interface, and gain
> connectivity to the "inside" interface across said VPN?  I've been
able
> to do similar things with IOS routers in the past, I just can't nail
> down from the documentation if this would be allowed on an ASA
> utilizing
> the included restricted VLAN.  Thanks in advance for any insight.
> 
> Regards,
> 
> dtb
<snip>

What do you mean by restricted VLAN?  The inside and outside, let's call
them VLAN 1 and VLAN 2, should both work unrestricted.  The restricted
VLAN is the third VLAN you would use for a DMZ.  If you go with the two
regular VLAN's then you will be able to establish VPN connectivity from
outside to inside with no technical difficulties.  You may, however,
have licensing restrictions if you're attempting to do SSL-based VLAN's.

Regards,

Mike

From judah.scott.iam at gmail.com  Tue Sep 15 18:50:09 2009
From: judah.scott.iam at gmail.com (Judah Scott)
Date: Tue, 15 Sep 2009 15:50:09 -0700
Subject: [c-nsp] RSVP MPLS Fast Reroute PLR Behavior
Message-ID: <3172b9cb0909151550k51d118d6o43259f3b7d4d1935@mail.gmail.com>

While testing out Fast Reroute I notice that after a linkdown and successful
FRR switch onto bypass, the SUT does not switch back to the primary path
after link is restored and IGP reconverges.  Is this expected behavior or am
I perhaps missing some important config statement?  I am testing on 7609s
with version 12.2(33)SRD.

Thanks,
J Scott

From td_miles at yahoo.com  Tue Sep 15 21:39:39 2009
From: td_miles at yahoo.com (Tony)
Date: Tue, 15 Sep 2009 18:39:39 -0700 (PDT)
Subject: [c-nsp] debug bgp updates within VRF
In-Reply-To: <7db92dcc0909150531h149c3b34udd9272e24201d30a@mail.gmail.com>
Message-ID: <387871.48034.qm@web110112.mail.gq1.yahoo.com>

Hi Biddu,

If you wish to see route table updates, then you can use "debug ip routing vrf <name>". This will show you the updates as they are applied to the VRF routing table.

If you wish to see what BGP specifically is doing then something like "deb ip bgp vpnv4 unicast updates" should help you out. You will see routes like  "100:1:10.200.0.189/32" which is 10.200.0.189 for VRF with RD 100:1.


Hope this helps.

regards,
Tony.




--- On Tue, 15/9/09, Ved Labs <vedlabs at gmail.com> wrote:

> From: Ved Labs <vedlabs at gmail.com>
> Subject: [c-nsp] debug bgp updates within VRF
> To: cisco-nsp at puck.nether.net
> Received: Tuesday, 15 September, 2009, 10:31 PM
> How do i *debug bgp updates within
> VRF*
> **
> *Thanks,*
> *Biddu.*



      __________________________________________________________________________________
Get more done like never before with Yahoo!7 Mail.
Learn more: http://au.overview.mail.yahoo.com/

From sthaug at nethelp.no  Wed Sep 16 01:22:52 2009
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Wed, 16 Sep 2009 07:22:52 +0200 (CEST)
Subject: [c-nsp] RSVP MPLS Fast Reroute PLR Behavior
In-Reply-To: <3172b9cb0909151550k51d118d6o43259f3b7d4d1935@mail.gmail.com>
References: <3172b9cb0909151550k51d118d6o43259f3b7d4d1935@mail.gmail.com>
Message-ID: <20090916.072252.74720247.sthaug@nethelp.no>

> While testing out Fast Reroute I notice that after a linkdown and successful
> FRR switch onto bypass, the SUT does not switch back to the primary path
> after link is restored and IGP reconverges.  Is this expected behavior or am
> I perhaps missing some important config statement?  I am testing on 7609s
> with version 12.2(33)SRD.

As far as I know this the expected behavior. MPLS explicit LSPs will
be reoptimized at intervals you specify, but it doesn't necessarily
happen right away. We have typically configured a reoptimization
interval of 1 hour.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From rwest at zyedge.com  Wed Sep 16 02:27:02 2009
From: rwest at zyedge.com (Ryan West)
Date: Wed, 16 Sep 2009 02:27:02 -0400
Subject: [c-nsp] ASA5505, Restricted VLAN & VPN
In-Reply-To: <4AB0068C.5040708@brockmans.com>
References: <4AB0068C.5040708@brockmans.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124C180EA4F@zy-ex1.zyedge.local>

Dave,

Have you checked out the logs.  I think you should see your answer there.  Even if the tunnel came up properly, the ASA would still detect that it's coming from the "DMZ VLAN" and drop the connections.  The only option is connections from the inside or outside VLANs into the DMZ VLAN.

http://www.cisco.com/en/US/docs/security/asa/asa80/getting_started/asa5505/quick/guide/vlans.html#wp1101628

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Dave Brockman
Sent: Tuesday, September 15, 2009 5:27 PM
To: Cisco Mailing list
Subject: [c-nsp] ASA5505, Restricted VLAN & VPN

I have a client with an ASA5505, base license, currently utilizing the
"restricted" VLAN to provide access to the internet only, across the
"outside" interface.  Is it possible to make a VPN connection from the
restricted VLAN via (I assume) the "outside" interface, and gain
connectivity to the "inside" interface across said VPN?  I've been able
to do similar things with IOS routers in the past, I just can't nail
down from the documentation if this would be allowed on an ASA utilizing
the included restricted VLAN.  


From peter.hicks at poggs.co.uk  Wed Sep 16 02:57:06 2009
From: peter.hicks at poggs.co.uk (Peter Hicks)
Date: Wed, 16 Sep 2009 07:57:06 +0100
Subject: [c-nsp] ifType of 877W ATM and ADSL interfaces
Message-ID: <4AB08C42.9000904@poggs.co.uk>

Hello

I have an 877W with IOS 12.4(22)T1 here, and I am writing some code to 
interpret ATM and ADSL stats from the router.

IF-MIB::ifTable shows "ATM0" as being of type adsl(94), "ATM0-atm layer" 
as being of type atm(37) and "ATM0-adsl" as being of type adsl(94).

ATM-MIB::atmVclTable has entries for ATM0, even though this is an 'adsl' 
interface.  This seems wrong - should the entries not be indexed for the 
'atm(37)' interface?

Also, if there are two interfaces with type 'adsl(94)', why is it that 
the second - "ATM0-adsl" - only has entries in the ADSL-LINE-MIB?  ISTM 
the ifTypes are set incorrectly, and maybe ATM0 should have an ifType to 
more accurately reflect what it is.

I am thoroughly confused - is this a bug in the SNMP agent?

Regards,


Peter

From vedlabs at gmail.com  Wed Sep 16 03:13:53 2009
From: vedlabs at gmail.com (Ved Labs)
Date: Wed, 16 Sep 2009 12:43:53 +0530
Subject: [c-nsp] 2950 issues - Link comes UP only after reboot - Wimax
Message-ID: <7db92dcc0909160013t3cd5dfeey3c18417bffc32a79@mail.gmail.com>

Observing starnge problem in WS-C2950G-24-EI switches.
The link goes down and does not comes up .

Link cames up only , when the switch is rebooted manually.
change patch cord and change Gibic module does not help

UDLD messages are observed . but after the reboot , the switch becomes OK.

Thanks,
Biddu.

From gert at greenie.muc.de  Wed Sep 16 03:40:44 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 16 Sep 2009 09:40:44 +0200
Subject: [c-nsp] Cat 4948 NAT support
In-Reply-To: <20090914190205.GA57486@geeks.org>
References: <mailman.68.1251925701.2225.cisco-nsp@puck.nether.net>
	<1AD3CD5F-2BBD-4B9A-88A0-F3A2D0166257@swingpad.com>
	<20090914190205.GA57486@geeks.org>
Message-ID: <20090916074044.GU1508@greenie.muc.de>

Hi,

On Mon, Sep 14, 2009 at 02:02:05PM -0500, Doug McIntyre wrote:
> So, don't go searching for switches that support NAT, the Cat6500 is it. 

But there are caveats - not all IP protocols are supported in the hardware
path.  I seem to remember postings on this lists that had somewhat unusual
traffic (GRE tunnels?) going through a 6500, and that was all done in
software.

> Cisco leaves NAT to firewalls and routers, not switches. 

Just don't do NAT in the first place.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090916/035e5789/attachment.bin>

From tomas at soitron.com  Wed Sep 16 04:01:37 2009
From: tomas at soitron.com (Daniska, Tomas)
Date: Wed, 16 Sep 2009 10:01:37 +0200
Subject: [c-nsp] instabilities with SXI2?
In-Reply-To: <6D1685A7-18DE-4A1F-9D77-63AA61EFCCA9@puck.nether.net>
References: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>
	<4A9CDB6A.6080607@imperial.ac.uk>
	<435002.85345.qm@web1214.biz.mail.gq1.yahoo.com>
	<026e01ca357c$8ac6c660$a0545320$@com>
	<20090914213415.GL1508@greenie.muc.de>
	<20090914215307.GB26122@lboro.ac.uk>
	<6D1685A7-18DE-4A1F-9D77-63AA61EFCCA9@puck.nether.net>
Message-ID: <6B43981C32F8464CB24CEE209DA32BD3025A215F@kenya.tronet.as>

> -----Original Message-----
> From: Jared Mauch [mailto:jared at puck.nether.net]
> Sent: Tuesday, September 15, 2009 12:27 AM
> 
> I have a long laundry list of bugs in SXI2, including one that I've
> not quite yet isolated when you have several levels of recursion on
> routes causing it to take quite some time to finally settle down after
> a network event.  We don't see the same problem in pre-cef/mfi code
> (ie: SXF) but do see poor convergence properties in SXH/SXI.
> 

To add to the list. The customer is SXI2a modular already.

We had pretty long responses to sh run two days ago. Turned out to be
the SP at 100% indefinitely. No log events that'd suggest a reason, no
excessive amounts of traffic. No idea so far, working with TAC.

--

deejay

 

__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4423
(20090914) __________

Tuto spravu preveril ESET NOD32 Antivirus.

http://www.eset.sk
 

From gert at greenie.muc.de  Wed Sep 16 04:04:29 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 16 Sep 2009 10:04:29 +0200
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <90758F88-6F72-4458-BB83-0917C31C2EB7@puck.nether.net>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
	<373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>
	<CD0195AB-DF6F-4B41-83BD-0E6F5F0BADF9@puck.nether.net>
	<20090914143623.GE1508@greenie.muc.de>
	<90758F88-6F72-4458-BB83-0917C31C2EB7@puck.nether.net>
Message-ID: <20090916080429.GW1508@greenie.muc.de>

Hi,

On Mon, Sep 14, 2009 at 10:47:17AM -0400, Jared Mauch wrote:
> On Sep 14, 2009, at 10:36 AM, Gert Doering wrote:
> 
> >On Mon, Sep 14, 2009 at 09:52:36AM -0400, Jared Mauch wrote:
> >>While you're at it, ask for protected memory in the software.  It's
> >>not like ram/flash are expensive these days...
> >
> >Does "modular" have that?  Or not yet?
> >
> >(I want to see modular on *all* IOS based platforms, and not as a
> >somewhat-neglected step child on one specific niche platform that
> >is actually fighting with another BU for line card support...  or if
> >that is not feasible, completely abandon IOS and provide XE or NX-OS
> >on *all* platforms)
> 
> The modular that showed up on 65xx was because 65xx saw value in it.   
> No other platform sees the same value, meaning no protected memory for  
> you.

Between your lines, I read "modular *has* protected memory", which is 
a good thing - we bought $lots of 6506's last year specifically because
we wanted to run modular on it (and did not get RSP720s + 7600s).

> It's sad when you see all the effort that went into the modular over  
> the years being thrown away/ignored then keep having devices crash  
> with more catastrophic outcomes and no usable debugging information.

Yes.  Stupid company, this one.

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090916/49b1da1d/attachment.bin>

From gert at greenie.muc.de  Wed Sep 16 04:06:39 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 16 Sep 2009 10:06:39 +0200
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <20090914163011.GC25690@lboro.ac.uk>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
	<373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>
	<CD0195AB-DF6F-4B41-83BD-0E6F5F0BADF9@puck.nether.net>
	<20090914143623.GE1508@greenie.muc.de>
	<20090914163011.GC25690@lboro.ac.uk>
Message-ID: <20090916080639.GX1508@greenie.muc.de>

Hi,

On Mon, Sep 14, 2009 at 05:30:11PM +0100, Alan Buxey wrote:
> > that is not feasible, completely abandon IOS and provide XE or NX-OS
> > on *all* platforms)
> 
> NX-OS on all platforms? nothanks - some of us want functionality ;-)

The problem with the multitude of different operating systems in that
company is that their development efforts are so horribly fragmented.

Just imagine how much functionality NX-OS could get if they would stop
wasting effort on 17 different software trains for "classic IOS" and
instead focus on getting NX-OS on all hardware platforms, and getting
feature parity for it.

Yes, I'm now going to wake up, it's grey and foggy outside and I have
to go to work...

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090916/a98a0e33/attachment-0001.bin>

From wim.holemans at ua.ac.be  Wed Sep 16 04:40:06 2009
From: wim.holemans at ua.ac.be (Holemans Wim)
Date: Wed, 16 Sep 2009 10:40:06 +0200
Subject: [c-nsp] 2801 as console server
Message-ID: <A9C0DC3E3383224B83C528B074390E8C1298F1@xmail04.ad.ua.ac.be>

I've been looking through the Cisco doc but didn't found what I was
looking for, therefor this question :

 

I transformed a 2801 router which we used as a dialin server to a
console server. The config seems to work, I can do a 

telnet xxx 2018  to get access to serial port 0/1/1, also ssh -l
user:portnumber works. But I still have 2 problems :

-    The escape character doesn't work when using ssh, also e.g.
defining CTRL-Z as disconnect character doesn't work. The only way to
stop the connection, is by killing it at the ssh client side. Is there
another way to stop the ssh connection, just like the telnet escape
character ?

-    Is there a way to access the async line from within the router
itself ? So just a telnet/ssh to the router and then something like
'connect line XXX'  ? The connect command on the router seems an
equivalent of telnet for outgoing tcp sessions and I don't see another
command that could do this.

 

I'm running c2801-ipbasek9-mz.124-25a on the router.

Thanks,

 

 

Wim Holemans

Netwerkdienst Universiteit Antwerpen

 


From ronan at iol.ie  Wed Sep 16 05:17:49 2009
From: ronan at iol.ie (Ronan Mullally)
Date: Wed, 16 Sep 2009 10:17:49 +0100 (IST)
Subject: [c-nsp] 2801 as console server
In-Reply-To: <A9C0DC3E3383224B83C528B074390E8C1298F1@xmail04.ad.ua.ac.be>
References: <A9C0DC3E3383224B83C528B074390E8C1298F1@xmail04.ad.ua.ac.be>
Message-ID: <alpine.DEB.2.00.0909161016000.3676@luggage>

Hi Wim,

On Wed, 16 Sep 2009, Holemans Wim wrote:

> -    Is there a way to access the async line from within the router
> itself ? So just a telnet/ssh to the router and then something like
> 'connect line XXX'  ? The connect command on the router seems an
> equivalent of telnet for outgoing tcp sessions and I don't see another
> command that could do this.

I've done this in the past by connecting to an IP address on the router -
the one assigned to the ethernet interface for example.  We use a 2511 as
a console server for last resort access to devices.  In the worst case
scenario if the ethernet interface is down we access it via the console
port.  If that's the case then the ethernet IP address won't be reachable.
I've assigned a loopback IP address (192.168.0.0/32 I think) and use that
instead ("router> telnet 192.168.0.0 2001")

Hope this helps.


-Ronan

From b.turnbow at twt.it  Wed Sep 16 06:14:08 2009
From: b.turnbow at twt.it (Brian Turnbow)
Date: Wed, 16 Sep 2009 12:14:08 +0200
Subject: [c-nsp] 2801 as console server
In-Reply-To: <alpine.DEB.2.00.0909161016000.3676@luggage>
References: <A9C0DC3E3383224B83C528B074390E8C1298F1@xmail04.ad.ua.ac.be>
	<alpine.DEB.2.00.0909161016000.3676@luggage>
Message-ID: <F2207DB22012F94E92D7030F81A26294029948D4@twt-exch.milano.twt>



>> -    Is there a way to access the async line from within the router
>> itself ? So just a telnet/ssh to the router and then something like
>> 'connect line XXX'  ? The connect command on the router seems an
>> equivalent of telnet for outgoing tcp sessions and I don't see
another
>> command that could do this.

>I've done this in the past by connecting to an IP address on the router
-
>the one assigned to the ethernet interface for example.  We use a 2511
as
>a console server for last resort access to devices.  In the worst case
>scenario if the ethernet interface is down we access it via the console
>port.  If that's the case then the ethernet IP address won't be
reachable.
>I've assigned a loopback IP address (192.168.0.0/32 I think) and use
that
>instead ("router> telnet 192.168.0.0 2001")

If you create aliases on the router you can then just use the router
name for example

ip host accessjn2 2002 192.168.7.4
ip host accessjn3 2003 192.168.7.4
ip host accessjn6 2006 192.168.7.4

Then just 
telnet accessjn2


Brian


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From mat_cameron at msn.com  Wed Sep 16 07:27:47 2009
From: mat_cameron at msn.com (Mat Cameron)
Date: Wed, 16 Sep 2009 12:27:47 +0100
Subject: [c-nsp] Inter-AS M-VPNs
Message-ID: <COL117-W30C71F7E45B36836CB2ED9BE20@phx.gbl>


I am running with 

_________________________________________________________________
Save time by using Hotmail to access your other email accounts.
http://clk.atdmt.com/UKM/go/167688463/direct/01/

From mat_cameron at msn.com  Wed Sep 16 07:40:58 2009
From: mat_cameron at msn.com (Mat Cameron)
Date: Wed, 16 Sep 2009 12:40:58 +0100
Subject: [c-nsp] (no subject)
Message-ID: <COL117-W15DFB019631881C82C6A489BE20@phx.gbl>


I am running with a project at the moment with regards to getting Inter-AS mvpns working ALL hardware is Cisco. If I read all the material correctly and I would like some clarification, I cannot use non MDT SAFI capable router as Route-Reflectors, as type 2 RDs are non-transitive. The challenge I have is that nearly all my PEs are non MDT SAFi capable, although I can implement MDT SAFI capable Route-Reflectors. So with that prospect does anyone see me having a problem implementing MDT SAFI capable RRs with non MDT SAFI capable PEs and using Cisco's "MVPN Inter-AS Support Option C"

Thanks in advance

Mat

_________________________________________________________________
Use Hotmail to send and receive mail from your different email accounts.
http://clk.atdmt.com/UKM/go/167688463/direct/01/

From lobotiger at gmail.com  Wed Sep 16 08:40:40 2009
From: lobotiger at gmail.com (Lobo)
Date: Wed, 16 Sep 2009 08:40:40 -0400
Subject: [c-nsp] Help with unique BGP setup
Message-ID: <4AB0DCC8.5070000@gmail.com>

We're trying to do a custom bgp setup for one of our customers but I'm 
not sure if it's even possible with IOS.  Our network has its primary 
upstream connection in a different city from where this customer will 
connect.  However each city has its own local internet connection as 
well for backup purposes.  The market that this bgp customer is to be 
turned up on uses the local isp connection as its primary due to 
capacity issues on the intercity going back to the core city.

This customer's requirements for bandwidth can be met if they use the 
local connection only but should the connection go down, they would most 
likely saturate the intercity connection and impact everyone else.  What 
has been proposed is that they will use the local connection to get 
internet access and should this access go down, they want the bgp 
session to be dropped or something equivalent that will make sure they 
don't go over the intercity.

To my knowledge I know of no configuration that can drop a bgp session 
based on some next hop attribute.  Is there some way to control this 
customer's traffic as stated above?  Any examples you guys can offer?

Thanks.

Jose

From ml at kenweb.org  Wed Sep 16 09:07:13 2009
From: ml at kenweb.org (ML)
Date: Wed, 16 Sep 2009 09:07:13 -0400
Subject: [c-nsp] Help with unique BGP setup
In-Reply-To: <4AB0DCC8.5070000@gmail.com>
References: <4AB0DCC8.5070000@gmail.com>
Message-ID: <4AB0E301.7030602@kenweb.org>

Lobo wrote:
> We're trying to do a custom bgp setup for one of our customers but I'm 
> not sure if it's even possible with IOS.  Our network has its primary 
> upstream connection in a different city from where this customer will 
> connect.  However each city has its own local internet connection as 
> well for backup purposes.  The market that this bgp customer is to be 
> turned up on uses the local isp connection as its primary due to 
> capacity issues on the intercity going back to the core city.
> 
> This customer's requirements for bandwidth can be met if they use the 
> local connection only but should the connection go down, they would most 
> likely saturate the intercity connection and impact everyone else.  What 
> has been proposed is that they will use the local connection to get 
> internet access and should this access go down, they want the bgp 
> session to be dropped or something equivalent that will make sure they 
> don't go over the intercity.
> 
> To my knowledge I know of no configuration that can drop a bgp session 
> based on some next hop attribute.  Is there some way to control this 
> customer's traffic as stated above?  Any examples you guys can offer?
> 
> Thanks.
> 
> Jose

Can you only advertise their prefixes out of the local upstream?



From petelists at templin.org  Wed Sep 16 09:08:56 2009
From: petelists at templin.org (Pete Templin)
Date: Wed, 16 Sep 2009 08:08:56 -0500
Subject: [c-nsp] Help with unique BGP setup
In-Reply-To: <4AB0DCC8.5070000@gmail.com>
References: <4AB0DCC8.5070000@gmail.com>
Message-ID: <4AB0E368.9060601@templin.org>

Lobo wrote:

> This customer's requirements for bandwidth can be met if they use the 
> local connection only but should the connection go down, they would most 
> likely saturate the intercity connection and impact everyone else.  What 
> has been proposed is that they will use the local connection to get 
> internet access and should this access go down, they want the bgp 
> session to be dropped or something equivalent that will make sure they 
> don't go over the intercity.

We have the ability to do this in our network through the use of 
communities.  We'd tag the customer's incoming routes with 
our-ASN:2XX02, and the trailing '2' would tell the local city to 
advertise it (by matching the XX POP code) and the remote cities to not 
advertise it (by not-matching the XX POP code).  We'd selectively filter 
what routes we sent to the customer by limiting them to our-ASN:2.... 
(any customer in any POP), our-ASN:3.... (our routes in any POP), and 
our-ASN:4XX.. (upstream routes in this POP).  In this case, the session 
wouldn't go down, but the customer's routes wouldn't go to other markets 
(and therefore out the main upstream connection), and the customer would 
only receive external routes from the local connection(s).

We do this by sticking a coded community on EVERY route that goes into 
BGP at the point that the route enters our BGP mesh.  We redistribute 
connected and static routes into BGP through a route-map, and apply an 
inbound route-map to all BGP neighbors, then "send-community" to the 
rest of our iBGP mesh.  The coded community is our-ASN:ABCDE, where A 
represents the type of route (customer, ours, upstream), BC represents 
the POP number (I sorted them alphabetically; any new POPs just go on 
the end of the list), D represents how strong/weak we want the traffic 
to come in (useful by customers who want to use us a little less or as 
pure backup), and E signals our georouting (MED) logic (0 means bring it 
in through any POP, 1 means steer it towards the nearest POPs, 2 means 
this POP only).  It's worked exceptionally well in a huge variety of 
scenarios, and I'm painfully having to extend it to our parent network 
now that we've been acquired.

pt

From zoe-nsp at complicity.co.uk  Wed Sep 16 08:55:27 2009
From: zoe-nsp at complicity.co.uk (Zoe O'Connell)
Date: Wed, 16 Sep 2009 13:55:27 +0100
Subject: [c-nsp] Help with unique BGP setup
In-Reply-To: <4AB0DCC8.5070000@gmail.com>
References: <4AB0DCC8.5070000@gmail.com>
Message-ID: <4AB0E03F.6090708@complicity.co.uk>

Lobo wrote:
> We're trying to do a custom bgp setup for one of our customers but I'm
> not sure if it's even possible with IOS.  Our network has its primary
> upstream connection in a different city from where this customer will
> connect.  However each city has its own local internet connection as
> well for backup purposes.  The market that this bgp customer is to be
> turned up on uses the local isp connection as its primary due to
> capacity issues on the intercity going back to the core city.
>
> This customer's requirements for bandwidth can be met if they use the
> local connection only but should the connection go down, they would
> most likely saturate the intercity connection and impact everyone
> else.  What has been proposed is that they will use the local
> connection to get internet access and should this access go down, they
> want the bgp session to be dropped or something equivalent that will
> make sure they don't go over the intercity.
>
> To my knowledge I know of no configuration that can drop a bgp session
> based on some next hop attribute.  Is there some way to control this
> customer's traffic as stated above?  Any examples you guys can offer?

Do you actually need to drop the session, or is it sufficient to
advertise zero prefixes? If the latter, you could apply a route-map
outbound towards the customer that only allows the "local" internet
routes to be advertised to them, by setting/matching communities
appropriately. For example:

route-map transit-in permit 10
 set community YOURAS:1234

ip community-list standard LOCAL-ROUTES permit YOURAS:1234

route-map customer-out permit 10
 match community LOCAL-ROUTES

Similar can be applied in reverse to prevent the customer's routes being
advertised out transit links other than the local one.



From NMaio at guesswho.com  Wed Sep 16 09:45:46 2009
From: NMaio at guesswho.com (NMaio at guesswho.com)
Date: Wed, 16 Sep 2009 09:45:46 -0400
Subject: [c-nsp] ASA Licensing
Message-ID: <2AA600764E54964491083B1E0EC81A301E240BFF26@EXCLUS.nationala-1advertising.com>

Does anybody know if it is possible to run the AnyConnect Essentials license and a small 10 user ssl license to allow only 10 people access to the webportal but all the rest to use the AnyConnect client.

From dwhitejr at cisco.com  Wed Sep 16 10:03:33 2009
From: dwhitejr at cisco.com (David White, Jr. (dwhitejr))
Date: Wed, 16 Sep 2009 10:03:33 -0400
Subject: [c-nsp] ASA Licensing
In-Reply-To: <2AA600764E54964491083B1E0EC81A301E240BFF26@EXCLUS.nationala-1advertising.com>
References: <2AA600764E54964491083B1E0EC81A301E240BFF26@EXCLUS.nationala-1advertising.com>
Message-ID: <4AB0F035.4010600@cisco.com>

That is not currently possible.   Once AnyConnect Essentials is enabled,
Clientless (webportal) VPN will be disabled, along with CSD.  Users
accessing the ASA via the web page will automatically be sent to the
AnyConnect Web launch after successful authentication.

Sincerely,

David.

NMaio at guesswho.com wrote:
> Does anybody know if it is possible to run the AnyConnect Essentials license and a small 10 user ssl license to allow only 10 people access to the webportal but all the rest to use the AnyConnect client.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   


From NMaio at guesswho.com  Wed Sep 16 10:07:43 2009
From: NMaio at guesswho.com (NMaio at guesswho.com)
Date: Wed, 16 Sep 2009 10:07:43 -0400
Subject: [c-nsp] ASA Licensing
In-Reply-To: <4AB0F035.4010600@cisco.com>
References: <2AA600764E54964491083B1E0EC81A301E240BFF26@EXCLUS.nationala-1advertising.com>
	<4AB0F035.4010600@cisco.com>
Message-ID: <2AA600764E54964491083B1E0EC81A301E240BFF2B@EXCLUS.nationala-1advertising.com>

Thank you.  Exactly what I was looking for.

-----Original Message-----
From: David White, Jr. (dwhitejr) [mailto:dwhitejr at cisco.com] 
Sent: Wednesday, September 16, 2009 10:04 AM
To: Nicholas Maio
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA Licensing

That is not currently possible.   Once AnyConnect Essentials is enabled,
Clientless (webportal) VPN will be disabled, along with CSD.  Users
accessing the ASA via the web page will automatically be sent to the
AnyConnect Web launch after successful authentication.

Sincerely,

David.

NMaio at guesswho.com wrote:
> Does anybody know if it is possible to run the AnyConnect Essentials license and a small 10 user ssl license to allow only 10 people access to the webportal but all the rest to use the AnyConnect client.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   


From rwest at zyedge.com  Wed Sep 16 10:22:13 2009
From: rwest at zyedge.com (Ryan West)
Date: Wed, 16 Sep 2009 10:22:13 -0400
Subject: [c-nsp] ASA Licensing
In-Reply-To: <4AB0F035.4010600@cisco.com>
References: <2AA600764E54964491083B1E0EC81A301E240BFF26@EXCLUS.nationala-1advertising.com>
	<4AB0F035.4010600@cisco.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124C180EA73@zy-ex1.zyedge.local>

David,

Does this mean that DAP policies that may leverage CSD returned registry values will not work with Essentials?

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David White, Jr. (dwhitejr)
Sent: Wednesday, September 16, 2009 10:04 AM
To: NMaio at guesswho.com
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA Licensing

That is not currently possible.   Once AnyConnect Essentials is enabled,
Clientless (webportal) VPN will be disabled, along with CSD.  Users
accessing the ASA via the web page will automatically be sent to the
AnyConnect Web launch after successful authentication.

Sincerely,

David.


From BBlackford at nwresd.k12.or.us  Wed Sep 16 10:40:59 2009
From: BBlackford at nwresd.k12.or.us (Bill Blackford)
Date: Wed, 16 Sep 2009 07:40:59 -0700
Subject: [c-nsp] instabilities with SXI2?
In-Reply-To: <6B43981C32F8464CB24CEE209DA32BD3025A215F@kenya.tronet.as>
References: <6B43981C32F8464CB24CEE209DA32BD302516E1A@kenya.tronet.as>
	<4A9CDB6A.6080607@imperial.ac.uk>
	<435002.85345.qm@web1214.biz.mail.gq1.yahoo.com>
	<026e01ca357c$8ac6c660$a0545320$@com>	<20090914213415.GL1508@greenie.muc.de>
	<20090914215307.GB26122@lboro.ac.uk>
	<6D1685A7-18DE-4A1F-9D77-63AA61EFCCA9@puck.nether.net>
	<6B43981C32F8464CB24CEE209DA32BD3025A215F@kenya.tronet.as>
Message-ID: <6069A203FD01884885C037F81DD75080171E164FFC@wsc-mail-01.intra.nwresd.k12.or.us>

I have an issue where after setting up a BGP peer on one side, then issuing a 'sh run | b router bgp' to check my config before going to the adjacent peer and setting that side up, the command hung. As it turns out the active sup (I suppose the RP) crashed and failed over to the hot spare. Prior to this, the day prior, I added 'bgp graceful-restart' in support of SSO/NSF. I am working with Cisco TAC on this issue. No root cause yet.

6509
Sup720-3bxl
SXI2
X6748-ge-tx - no DFC

-b



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Daniska, Tomas
Sent: Wednesday, September 16, 2009 1:02 AM
To: Jared Mauch; Alan Buxey
Cc: Gert Doering; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] instabilities with SXI2?

> -----Original Message-----
> From: Jared Mauch [mailto:jared at puck.nether.net]
> Sent: Tuesday, September 15, 2009 12:27 AM
> 
> I have a long laundry list of bugs in SXI2, including one that I've
> not quite yet isolated when you have several levels of recursion on
> routes causing it to take quite some time to finally settle down after
> a network event.  We don't see the same problem in pre-cef/mfi code
> (ie: SXF) but do see poor convergence properties in SXH/SXI.
> 

To add to the list. The customer is SXI2a modular already.

We had pretty long responses to sh run two days ago. Turned out to be
the SP at 100% indefinitely. No log events that'd suggest a reason, no
excessive amounts of traffic. No idea so far, working with TAC.

--

deejay

 

__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4423
(20090914) __________

Tuto spravu preveril ESET NOD32 Antivirus.

http://www.eset.sk
 
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From dwhitejr at cisco.com  Wed Sep 16 11:01:38 2009
From: dwhitejr at cisco.com (David White, Jr. (dwhitejr))
Date: Wed, 16 Sep 2009 11:01:38 -0400
Subject: [c-nsp] ASA Licensing
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E140124C180EA73@zy-ex1.zyedge.local>
References: <2AA600764E54964491083B1E0EC81A301E240BFF26@EXCLUS.nationala-1advertising.com>
	<4AB0F035.4010600@cisco.com>
	<6E21B2BDEF6E714EA0B5BA8D5D0E140124C180EA73@zy-ex1.zyedge.local>
Message-ID: <4AB0FDD2.9070006@cisco.com>

Hi Ryan,

Yes, that is correct.  Since CSD is disabled, DAP cannot obtain any
host/registry values to make it's decisions.  However, AAA attributes
for DAP will still work.

Sincerely,

David.

Ryan West wrote:
> David,
>
> Does this mean that DAP policies that may leverage CSD returned registry values will not work with Essentials?
>
> -ryan
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David White, Jr. (dwhitejr)
> Sent: Wednesday, September 16, 2009 10:04 AM
> To: NMaio at guesswho.com
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASA Licensing
>
> That is not currently possible.   Once AnyConnect Essentials is enabled,
> Clientless (webportal) VPN will be disabled, along with CSD.  Users
> accessing the ASA via the web page will automatically be sent to the
> AnyConnect Web launch after successful authentication.
>
> Sincerely,
>
> David.
>
>   


From jfitz at Princeton.EDU  Wed Sep 16 11:48:16 2009
From: jfitz at Princeton.EDU (Jeff Fitzwater)
Date: Wed, 16 Sep 2009 11:48:16 -0400
Subject: [c-nsp] 3750 https bad certificate?
Message-ID: <DD6A73FD-B34D-42C1-9170-F8C0D626EBA2@Princeton.EDU>

I have a 3750 running 12.2.44

I have one or two units that I cannot https into because the  
certificate cannot be trusted.

Everything seems to point to the keys on the switch and even after  
generating new keys it still fails https.

I can ssh in to CLI, just can't https.


I have zeroized keys and disabled ip http secure-server and reenabled  
it, but still no luck.


I did not reset the switch yet.


Does anybody have any ideas on this.


I'am stuck.



Thanks in advance for any help.



Jeff Fitzwater
OIT Network Systems
Princeton University

From gsgranados at comcast.net  Wed Sep 16 12:03:58 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Wed, 16 Sep 2009 09:03:58 -0700
Subject: [c-nsp] Need a switch suggestion for upgrade
Message-ID: <01b401ca36e7$513d5640$2208120a@am.thmulti.com>

Hi List,
Presently I have two foundry FI400 switches in the core that provide layer 3 
functionality as well.  I'm serving about 20 access switches and a few 
virtual machine hosts in an enterprise environment with approximately 50 
VLANS.  We're outgrowing this and also since it's older hardware new 
firmware / features are hard to come by as well as support.;)  What would be 
a good Cisco product to replace these?  The big things I'm interested in are 
layer 3 routing (very simple mostly static) good multicast support (this 
customer is an IPTV developer) and decent gig port dencity (say 48 ports of 
gig or more)  Would a 4500 series fit the bill here or should I consider 
something else.  Someone familiar with Cisco switching products who has some 
good pointers please contact me.

Thank you
Scott


From tmyoungjr at gmail.com  Wed Sep 16 12:07:17 2009
From: tmyoungjr at gmail.com (Timothy Young)
Date: Wed, 16 Sep 2009 12:07:17 -0400
Subject: [c-nsp] 7600 weirdness
In-Reply-To: <1dc345f80909160853r1367d9ecj5159a672573efc94@mail.gmail.com>
References: <1dc345f80909160853r1367d9ecj5159a672573efc94@mail.gmail.com>
Message-ID: <1dc345f80909160907u249fd98bu511de7d0db6c3081@mail.gmail.com>

Hello,

I have a pair of 7606s running single SUP 720 ? 3BXLs with Version
12.2(18)SXF7 (IP Services)

What I saw last night is perplexing and mind you I?m not the greatest with
these devices.

Sep 15 18:39:04: %LINK-3-UPDOWN: Interface GigabitEthernet4/41, changed
state to up

Sep 15 18:39:04: %LINK-SP-3-UPDOWN: Interface GigabitEthernet4/41, changed
state to up

Sep 15 18:39:07: %LINEPROTO-5-UPDOWN: Line protocol on Interface
GigabitEthernet4/41, changed state to up

Sep 15 18:39:07: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface
GigabitEthernet4/41, changed state to up

Sep 15 18:39:08: %LINK-SP-3-UPDOWN: Interface GigabitEthernet1/2, changed
state to up

Sep 15 19:00:10: %LINEPROTO-5-UPDOWN: Line protocol on Interface
GigabitEthernet4/41, changed state to down

Sep 15 19:00:10: %LINK-3-UPDOWN: Interface GigabitEthernet4/41, changed
state to down

Sep 15 19:00:10: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface
GigabitEthernet4/41, changed state to down

Sep 15 19:00:10: %LINK-SP-3-UPDOWN: Interface GigabitEthernet4/41, changed
state to down

Sep 15 19:44:08: %LINEPROTO-5-UPDOWN: Line protocol on Interface
GigabitEthernet4/3, changed state to down

Sep 15 19:44:08: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface
GigabitEthernet4/3, changed state to down

Sep 15 19:44:08: %LINK-3-UPDOWN: Interface GigabitEthernet4/3, changed state
to down



So basically I have interfaces bouncing regularly ? but there?s 45 minutes
of time where nothing showed in my logs at all.

That is very uncommon, but what makes this perplexing is that the 7600 still
sent traps to my Solarwinds box about multiple port up / downs during the
19:00:10 to 19:44:08 timeframe.  Nothing else on the box had issues, I had
no network problems (my voice network would?ve flaked to high hell if I had
any cpu / network  issues).

My CPU holds between 20-30% at any given time ? with the occasional spike up
near 80ish (and when I say spike ? I literally mean momentarily ?it doesn?t
hold there at all).

The history for the CPU doesn?t show anything corresponding to that time
frame and even spikes.

Memory looks fine on the box with tons free.

What I?m looking for is where I can start looking on the box ? or ideas that
may help me sort out why the box seems to have flipped and stopped reporting
for a bit.

I?m familiar with the logging ? but anything more and it gets fuzzy for me.



Thanks


Tim

From peter at rathlev.dk  Wed Sep 16 12:44:55 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Wed, 16 Sep 2009 18:44:55 +0200
Subject: [c-nsp] 3750 https bad certificate?
In-Reply-To: <DD6A73FD-B34D-42C1-9170-F8C0D626EBA2@Princeton.EDU>
References: <DD6A73FD-B34D-42C1-9170-F8C0D626EBA2@Princeton.EDU>
Message-ID: <1253119495.2800.8.camel@abehat.net.rm.dk>

Hi Jeff,

On Wed, 2009-09-16 at 11:48 -0400, Jeff Fitzwater wrote:
> I have a 3750 running 12.2.44
> 
> I have one or two units that I cannot https into because the  
> certificate cannot be trusted.
> 
> Everything seems to point to the keys on the switch and even after  
> generating new keys it still fails https.
> 
> I can ssh in to CLI, just can't https.
> 
> I have zeroized keys and disabled ip http secure-server and reenabled
> it, but still no luck.

I assume that the certificates you generate on the switch are self
signed, and that would of course give a warning since the browser
doesn't trust the issuer, which is the switch itself.

> I did not reset the switch yet.
> 
> Does anybody have any ideas on this.

You either have to explicitely trust the self signed certificate or get
a certificate from a trusted CA.

Or am I misunderstanding you question?

Regards,
Peter



From drrtuy at ya.ru  Wed Sep 16 12:17:28 2009
From: drrtuy at ya.ru (Roman A. Nozdrin)
Date: Wed, 16 Sep 2009 19:17:28 +0300
Subject: [c-nsp] Help with unique BGP setup
In-Reply-To: <4AB0DCC8.5070000@gmail.com>
References: <4AB0DCC8.5070000@gmail.com>
Message-ID: <4AB10F98.7060008@ya.ru>

Lobo wrote:
> We're trying to do a custom bgp setup for one of our customers but I'm 
> not sure if it's even possible with IOS.  Our network has its primary 
> upstream connection in a different city from where this customer will 
> connect.  However each city has its own local internet connection as 
> well for backup purposes.  The market that this bgp customer is to be 
> turned up on uses the local isp connection as its primary due to 
> capacity issues on the intercity going back to the core city.
> 
> This customer's requirements for bandwidth can be met if they use the 
> local connection only but should the connection go down, they would most 
> likely saturate the intercity connection and impact everyone else.  What 
> has been proposed is that they will use the local connection to get 
> internet access and should this access go down, they want the bgp 
> session to be dropped or something equivalent that will make sure they 
> don't go over the intercity.
> 
> To my knowledge I know of no configuration that can drop a bgp session 
> based on some next hop attribute.  Is there some way to control this 
> customer's traffic as stated above?  Any examples you guys can offer?

I advise You to look at BGP conditional advertisement feature, which can 
be used on customers BGP peers. Hereby is an example.

neighbor city-link-nei-ip advertise-map cust-map non-exist-map checked-map

ip prefix-list cust-pref permit seq 5 permit cust-prefix/xx
ip prefix-list checked-pref permit seq 5 permit anyTIER1-pref/xx

route-map advertise-map permit 10
match ip address prefix-list cust-pref

route-map checked-map permit 10
match ip address prefix-list checked-pref

WBR
Roman A. Nozdrin

From achatz at forthnet.gr  Wed Sep 16 12:56:05 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Wed, 16 Sep 2009 19:56:05 +0300
Subject: [c-nsp] 7600 weirdness
In-Reply-To: <1dc345f80909160907u249fd98bu511de7d0db6c3081@mail.gmail.com>
References: <1dc345f80909160853r1367d9ecj5159a672573efc94@mail.gmail.com>
	<1dc345f80909160907u249fd98bu511de7d0db6c3081@mail.gmail.com>
Message-ID: <4AB118A5.80904@forthnet.gr>

I don't know how often you got the snmp traps, but maybe there was some micro flapping happening and the logging process 
didn't catch it.
I have seen many down/up snmp traps at the same time (*), while there where only a few of logging events (and no drops 
due to rate-limit). Besides checking for any "logging rate-limit" configs, "sh int x/x" can probably give you more 
details about actual resets.

* There is a bug on dot1-tunnel ports, where the reset of them causes cdp to be disabled. Many times, although there 
were no logs about down/up, cdp was disabled under these ports...probably due to a very fast reset.

--
Tassos

Timothy Young wrote on 16/09/2009 19:07:
> Hello,
> 
> I have a pair of 7606s running single SUP 720 ? 3BXLs with Version
> 12.2(18)SXF7 (IP Services)
> 
> What I saw last night is perplexing and mind you I?m not the greatest with
> these devices.
> 
> Sep 15 18:39:04: %LINK-3-UPDOWN: Interface GigabitEthernet4/41, changed
> state to up
> 
> Sep 15 18:39:04: %LINK-SP-3-UPDOWN: Interface GigabitEthernet4/41, changed
> state to up
> 
> Sep 15 18:39:07: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> GigabitEthernet4/41, changed state to up
> 
> Sep 15 18:39:07: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface
> GigabitEthernet4/41, changed state to up
> 
> Sep 15 18:39:08: %LINK-SP-3-UPDOWN: Interface GigabitEthernet1/2, changed
> state to up
> 
> Sep 15 19:00:10: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> GigabitEthernet4/41, changed state to down
> 
> Sep 15 19:00:10: %LINK-3-UPDOWN: Interface GigabitEthernet4/41, changed
> state to down
> 
> Sep 15 19:00:10: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface
> GigabitEthernet4/41, changed state to down
> 
> Sep 15 19:00:10: %LINK-SP-3-UPDOWN: Interface GigabitEthernet4/41, changed
> state to down
> 
> Sep 15 19:44:08: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> GigabitEthernet4/3, changed state to down
> 
> Sep 15 19:44:08: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface
> GigabitEthernet4/3, changed state to down
> 
> Sep 15 19:44:08: %LINK-3-UPDOWN: Interface GigabitEthernet4/3, changed state
> to down
> 
> 
> 
> So basically I have interfaces bouncing regularly ? but there?s 45 minutes
> of time where nothing showed in my logs at all.
> 
> That is very uncommon, but what makes this perplexing is that the 7600 still
> sent traps to my Solarwinds box about multiple port up / downs during the
> 19:00:10 to 19:44:08 timeframe.  Nothing else on the box had issues, I had
> no network problems (my voice network would?ve flaked to high hell if I had
> any cpu / network  issues).
> 
> My CPU holds between 20-30% at any given time ? with the occasional spike up
> near 80ish (and when I say spike ? I literally mean momentarily ?it doesn?t
> hold there at all).
> 
> The history for the CPU doesn?t show anything corresponding to that time
> frame and even spikes.
> 
> Memory looks fine on the box with tons free.
> 
> What I?m looking for is where I can start looking on the box ? or ideas that
> may help me sort out why the box seems to have flipped and stopped reporting
> for a bit.
> 
> I?m familiar with the logging ? but anything more and it gets fuzzy for me.
> 
> 
> 
> Thanks
> 
> 
> Tim
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


From lobotiger at gmail.com  Wed Sep 16 13:01:35 2009
From: lobotiger at gmail.com (Lobo)
Date: Wed, 16 Sep 2009 13:01:35 -0400
Subject: [c-nsp] Help with unique BGP setup
In-Reply-To: <4AB0E03F.6090708@complicity.co.uk>
References: <4AB0DCC8.5070000@gmail.com> <4AB0E03F.6090708@complicity.co.uk>
Message-ID: <4AB119EF.6080603@gmail.com>

Thanks for the responses everyone.  I like the idea of conditional 
advertisement and will likely work with something like that.  The 
session does not necessarily need to go down but advertising them 
nothing could work good.

Zoe, I like your method as well and will look at seeing if I can work 
something like that as well since we tag all of our local internet 
connections with specific communities that are unique per market.

Jose


Zoe O'Connell wrote:
> Lobo wrote:
>   
>> We're trying to do a custom bgp setup for one of our customers but I'm
>> not sure if it's even possible with IOS.  Our network has its primary
>> upstream connection in a different city from where this customer will
>> connect.  However each city has its own local internet connection as
>> well for backup purposes.  The market that this bgp customer is to be
>> turned up on uses the local isp connection as its primary due to
>> capacity issues on the intercity going back to the core city.
>>
>> This customer's requirements for bandwidth can be met if they use the
>> local connection only but should the connection go down, they would
>> most likely saturate the intercity connection and impact everyone
>> else.  What has been proposed is that they will use the local
>> connection to get internet access and should this access go down, they
>> want the bgp session to be dropped or something equivalent that will
>> make sure they don't go over the intercity.
>>
>> To my knowledge I know of no configuration that can drop a bgp session
>> based on some next hop attribute.  Is there some way to control this
>> customer's traffic as stated above?  Any examples you guys can offer?
>>     
>
> Do you actually need to drop the session, or is it sufficient to
> advertise zero prefixes? If the latter, you could apply a route-map
> outbound towards the customer that only allows the "local" internet
> routes to be advertised to them, by setting/matching communities
> appropriately. For example:
>
> route-map transit-in permit 10
>  set community YOURAS:1234
>
> ip community-list standard LOCAL-ROUTES permit YOURAS:1234
>
> route-map customer-out permit 10
>  match community LOCAL-ROUTES
>
> Similar can be applied in reverse to prevent the customer's routes being
> advertised out transit links other than the local one.
>
>
>   

From peter at rathlev.dk  Wed Sep 16 13:06:40 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Wed, 16 Sep 2009 19:06:40 +0200
Subject: [c-nsp] Configurable MAC address flap settings?
Message-ID: <1253120800.2800.14.camel@abehat.net.rm.dk>

Hi,

Does anybody know if there's some way to configure the MAC flapping
settings on a 3560/3750?

I would like to be able to specify how many changes with a certain time
period should make the switch log a flapping issue.

-- 
Peter



From nigel at theroys.me.uk  Wed Sep 16 06:42:39 2009
From: nigel at theroys.me.uk (Nigel Roy)
Date: Wed, 16 Sep 2009 11:42:39 +0100
Subject: [c-nsp] 2801 as console server
In-Reply-To: <A9C0DC3E3383224B83C528B074390E8C1298F1@xmail04.ad.ua.ac.be>
Message-ID: <2009916114239.784298@easynet-2438>

If you use the 6018 instead of 2018 you should find the control characters escape characters etc work.

2xxx are 7 bit connections
4xxx give echo - you don't want that
6xxx are 8 bit connections.

Don't remember trying it with ssh but the 6xxx are certainly better for connecting to Cisco devices via TS as it even allows you to get at the boot loader if you need to - however that does obviously have security implications!!

Regards Nigel


> I've been looking through the Cisco doc but didn't found what I was
> looking for, therefor this question :
>
>
> I transformed a 2801 router which we used as a dialin server to a
> console server. The config seems to work, I can do a
>
> telnet xxx 2018  to get access to serial port 0/1/1, also ssh -l
> user:portnumber works. But I still have 2 problems :
>
> -    The escape character doesn't work when using ssh, also e.g.
> defining CTRL-Z as disconnect character doesn't work. The only way
> to stop the connection, is by killing it at the ssh client side. Is
> there another way to stop the ssh connection, just like the telnet
> escape character ?
>
> -    Is there a way to access the async line from within the router
> itself ? So just a telnet/ssh to the router and then something like
> 'connect line XXX'  ? The connect command on the router seems an
> equivalent of telnet for outgoing tcp sessions and I don't see
> another command that could do this.
>
>
> I'm running c2801-ipbasek9-mz.124-25a on the router.
>
> Thanks,
>
>
> Wim Holemans
>
> Netwerkdienst Universiteit Antwerpen
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp archive at
> http://puck.nether.net/pipermail/cisco-nsp/

From jfitz at Princeton.EDU  Wed Sep 16 13:47:57 2009
From: jfitz at Princeton.EDU (Jeff Fitzwater)
Date: Wed, 16 Sep 2009 13:47:57 -0400
Subject: [c-nsp] 3750 https bad certificate?
In-Reply-To: <1253119495.2800.8.camel@abehat.net.rm.dk>
References: <DD6A73FD-B34D-42C1-9170-F8C0D626EBA2@Princeton.EDU>
	<1253119495.2800.8.camel@abehat.net.rm.dk>
Message-ID: <980EDB25-4BC0-449E-AB35-A2698008C641@Princeton.EDU>

Well it looks like the key storage, which is in NVRAM by default (from  
what I have read) was not there or corrupted. So doing a "crypto key  
storage nvram" fixed it.

No sure why but it works now.


Jeff


On Sep 16, 2009, at 12:44 PM, Peter Rathlev wrote:

> Hi Jeff,
>
> On Wed, 2009-09-16 at 11:48 -0400, Jeff Fitzwater wrote:
>> I have a 3750 running 12.2.44
>>
>> I have one or two units that I cannot https into because the
>> certificate cannot be trusted.
>>
>> Everything seems to point to the keys on the switch and even after
>> generating new keys it still fails https.
>>
>> I can ssh in to CLI, just can't https.
>>
>> I have zeroized keys and disabled ip http secure-server and reenabled
>> it, but still no luck.
>
> I assume that the certificates you generate on the switch are self
> signed, and that would of course give a warning since the browser
> doesn't trust the issuer, which is the switch itself.
>
>> I did not reset the switch yet.
>>
>> Does anybody have any ideas on this.
>
> You either have to explicitely trust the self signed certificate or  
> get
> a certificate from a trusted CA.
>
> Or am I misunderstanding you question?
>
> Regards,
> Peter
>
>


From brandon at burn.net  Wed Sep 16 14:19:15 2009
From: brandon at burn.net (Brandon Applegate)
Date: Wed, 16 Sep 2009 14:19:15 -0400 (EDT)
Subject: [c-nsp] RSP720-3CXL - 512k ipv4 route capacity ?
Message-ID: <alpine.DEB.1.00.0909161409440.31173@orbital.burn.net>

I'm pretty sure either I'm not understanding something architecuture-wise 
or we've enabled something globally that halves this.  The marketing sheet 
says this will do 1M ipv4 routes.  My show commands lead me to believe our 
systems will only do 512k.  Not a problem today (for full internet) but I 
would like to understand.  We are doing ipv4 only, some MPLS, nothing 
earth-shattering.  The command and output that leads me to post this is:

router# sh platform hardware capacity forwarding

<snip>

  Module              FIB TCAM usage:                     Total        Used     %Used
    1                     72 bits (IPv4, MPLS, EoM)      524288      293721     56%
                         144 bits (IP mcast, IPv6)      262144            8      1%

</snip>

This is half of the rated max for the 3CXL and double that of the 3C.  We 
are running ES+ line cards but we have some CFC-based cards in it as well. 
So my operating mode is still:

router# sh platform hardware pfc mode
PFC operating mode : PFC3CXL

Thanks in advance for any info.

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996
"SH1-0151.  This is the serial number, of our orbital gun."


From shimshah at cisco.com  Wed Sep 16 14:37:53 2009
From: shimshah at cisco.com (Shimol Shah)
Date: Wed, 16 Sep 2009 14:37:53 -0400
Subject: [c-nsp] RSP720-3CXL - 512k ipv4 route capacity ?
In-Reply-To: <alpine.DEB.1.00.0909161409440.31173@orbital.burn.net>
References: <alpine.DEB.1.00.0909161409440.31173@orbital.burn.net>
Message-ID: <4AB13081.2090500@cisco.com>

What exact flavor of ES card are you using ? 'sh mod <>'

Putting a ES20-3C in to a chassis with RSP720-3CXL lowers the
effective table capacity of the system to the level of 3C


Brandon Applegate said the following on 9/16/2009 2:19 PM:
> I'm pretty sure either I'm not understanding something 
> architecuture-wise or we've enabled something globally that halves 
> this.  The marketing sheet says this will do 1M ipv4 routes.  My show 
> commands lead me to believe our systems will only do 512k.  Not a 
> problem today (for full internet) but I would like to understand.  We 
> are doing ipv4 only, some MPLS, nothing earth-shattering.  The command 
> and output that leads me to post this is:
> 
> router# sh platform hardware capacity forwarding
> 
> <snip>
> 
>  Module              FIB TCAM usage:                     Total        
> Used     %Used
>    1                     72 bits (IPv4, MPLS, EoM)      524288      
> 293721     56%
>                         144 bits (IP mcast, IPv6)      262144            
> 8      1%
> 
> </snip>
> 
> This is half of the rated max for the 3CXL and double that of the 3C.  
> We are running ES+ line cards but we have some CFC-based cards in it as 
> well. So my operating mode is still:
> 
> router# sh platform hardware pfc mode
> PFC operating mode : PFC3CXL
> 
> Thanks in advance for any info.
> 
> -- 
> Brandon Applegate - CCIE 10273
> PGP Key fingerprint:
> 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996
> "SH1-0151.  This is the serial number, of our orbital gun."
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From sidney.boumendil at gmail.com  Wed Sep 16 14:38:34 2009
From: sidney.boumendil at gmail.com (Sidney Boumendil)
Date: Wed, 16 Sep 2009 20:38:34 +0200
Subject: [c-nsp] RSP720-3CXL - 512k ipv4 route capacity ?
In-Reply-To: <alpine.DEB.1.00.0909161409440.31173@orbital.burn.net>
References: <alpine.DEB.1.00.0909161409440.31173@orbital.burn.net>
Message-ID: <41522e900909161138u4e66f409ra87c312938082160@mail.gmail.com>

On Wed, Sep 16, 2009 at 8:19 PM, Brandon Applegate <brandon at burn.net> wrote:

> I'm pretty sure either I'm not understanding something architecuture-wise
> or we've enabled something globally that halves this.  The marketing sheet
> says this will do 1M ipv4 routes.


Hi,

It supports 1M ipv4 routes *only*. Default setup is 512K ipv4 and mpls + 256
ipv6 and mcast.
Use mls cef max in conf mode to reconfigure this.

HTH

Sidney

From erpa22276 at yahoo.com  Wed Sep 16 13:42:25 2009
From: erpa22276 at yahoo.com (Per A)
Date: Wed, 16 Sep 2009 10:42:25 -0700 (PDT)
Subject: [c-nsp] ASA: NAT based on destination URL?
Message-ID: <611626.85557.qm@web36207.mail.mud.yahoo.com>

I'm looking for an option to redirect some traffic from a web server that can not handle it's current load. 

For example, can I send traffic bound for hosta.domain.com/images to one NAT destination while traffic bound for hosta.domain.com/anythingelse to another NAT destination? 

This is a temporary work-around to buy the time it will take to rebuild the application. 

Would it be possible to use a Webtype Access List in conjuction with Policy NAT, for example? 

If that wouldn't work, is there functionality on the ASA platform that could be used to get this result? 

Thanks in advance for your help.
?
Per 


      

From peter at rathlev.dk  Wed Sep 16 14:43:11 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Wed, 16 Sep 2009 20:43:11 +0200
Subject: [c-nsp] RSP720-3CXL - 512k ipv4 route capacity ?
In-Reply-To: <alpine.DEB.1.00.0909161409440.31173@orbital.burn.net>
References: <alpine.DEB.1.00.0909161409440.31173@orbital.burn.net>
Message-ID: <1253126591.3685.4.camel@abehat.net.rm.dk>

Hi Brandon,

On Wed, 2009-09-16 at 14:19 -0400, Brandon Applegate wrote:
> I'm pretty sure either I'm not understanding something
> architecuture-wise or we've enabled something globally that halves
> this.  The marketing sheet says this will do 1M ipv4 routes.

It has 1M 72-bit TCAM "slots". Default partitioning reserves half for
72-bit entries (IPv4, MPLS) and half for 144-bit entries (IPv6),
resulting in what you see.

Look at the "mls cef maximum-routes" for adjusting the defaults.

Regards,
Peter



From cordmacleod at gmail.com  Wed Sep 16 14:48:37 2009
From: cordmacleod at gmail.com (Cord MacLeod)
Date: Wed, 16 Sep 2009 11:48:37 -0700
Subject: [c-nsp] 3560 arbitrarily  ignoring ACL
Message-ID: <CDE8B53C-EBFF-4788-8B96-3647FA61B30F@gmail.com>

All,

I've taken over a 3560 around 10 months ago, and it's been performing  
well until last night.  With no warning, no log output or anything to  
indicate trouble, it stopped processing one of my ACL rules.  I have  
about 100 rules in the ACL and this one is near the beginning.  It  
stopped allowing port 443 to a particular vip, which was alive and  
well at the time.  After creating a copy of the ACL and flipping from  
the original to the copy and back, all was well again.  Anyone know  
anything about this issue?

Cisco IOS Software, C3560 Software (C3560-ADVIPSERVICESK9-M), Version  
12.2(25)SEB4, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2005 by Cisco Systems, Inc.
Compiled Tue 30-Aug-05 17:56 by yenanh


Switch   Ports  Model              SW Version              SW Image
------   -----  -----              ----------              ----------
*    1   52     WS-C3560G-48TS     12.2(25)SEB4            C3560- 
ADVIPSERVICESK


From brandon at burn.net  Wed Sep 16 14:49:53 2009
From: brandon at burn.net (Brandon Applegate)
Date: Wed, 16 Sep 2009 14:49:53 -0400 (EDT)
Subject: [c-nsp] RSP720-3CXL - 512k ipv4 route capacity ?
In-Reply-To: <41522e900909161138u4e66f409ra87c312938082160@mail.gmail.com>
References: <alpine.DEB.1.00.0909161409440.31173@orbital.burn.net>
	<41522e900909161138u4e66f409ra87c312938082160@mail.gmail.com>
Message-ID: <alpine.DEB.1.00.0909161447520.31173@orbital.burn.net>

On Wed, 16 Sep 2009, Sidney Boumendil wrote:

>
> It supports 1M ipv4 routes *only*. Default setup is 512K ipv4 and mpls + 256
> ipv6 and mcast.
> Use mls cef max in conf mode to reconfigure this.
>
> HTH
>
> Sidney
>

This is exactly what I was looking for, thanks.

From david at hughes.com.au  Wed Sep 16 19:43:00 2009
From: david at hughes.com.au (David Hughes)
Date: Thu, 17 Sep 2009 09:43:00 +1000
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <20090916080639.GX1508@greenie.muc.de>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
	<373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>
	<CD0195AB-DF6F-4B41-83BD-0E6F5F0BADF9@puck.nether.net>
	<20090914143623.GE1508@greenie.muc.de>
	<20090914163011.GC25690@lboro.ac.uk>
	<20090916080639.GX1508@greenie.muc.de>
Message-ID: <0E0ADFB3-3D29-4857-B6B4-92E8698B026E@hughes.com.au>


On 16/09/2009, at 6:06 PM, Gert Doering wrote:

> Just imagine how much functionality NX-OS could get if they would stop
> wasting effort on 17 different software trains for "classic IOS" and
> instead focus on getting NX-OS on all hardware platforms, and getting
> feature parity for it.

Totally agree.  It looks like NX-OS has the sort of architecture we  
all want.  And it works.  And its reliable (MDS has been solid).  And  
its getting features quite quickly.  NX-OS on Cat6k and ASR?  Why  
not?  Other than BU politics naturally.


David
...

From tdurack at gmail.com  Wed Sep 16 20:00:33 2009
From: tdurack at gmail.com (Tim Durack)
Date: Wed, 16 Sep 2009 20:00:33 -0400
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <0E0ADFB3-3D29-4857-B6B4-92E8698B026E@hughes.com.au>
References: <200909081035.tcp24@psirt.cisco.com>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
	<373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>
	<CD0195AB-DF6F-4B41-83BD-0E6F5F0BADF9@puck.nether.net>
	<20090914143623.GE1508@greenie.muc.de>
	<20090914163011.GC25690@lboro.ac.uk>
	<20090916080639.GX1508@greenie.muc.de>
	<0E0ADFB3-3D29-4857-B6B4-92E8698B026E@hughes.com.au>
Message-ID: <9e246b4d0909161700h3e8ab19cx25ae520c19c99860@mail.gmail.com>

On Wed, Sep 16, 2009 at 7:43 PM, David Hughes <david at hughes.com.au> wrote:

>
> On 16/09/2009, at 6:06 PM, Gert Doering wrote:
>
>  Just imagine how much functionality NX-OS could get if they would stop
>> wasting effort on 17 different software trains for "classic IOS" and
>> instead focus on getting NX-OS on all hardware platforms, and getting
>> feature parity for it.
>>
>
> Totally agree.  It looks like NX-OS has the sort of architecture we all
> want.  And it works.  And its reliable (MDS has been solid).  And its
> getting features quite quickly.  NX-OS on Cat6k and ASR?  Why not?  Other
> than BU politics naturally.
>

That was my thinking. Unfortnately the Cisco Nexus guys have publicly stated
the C6K stays on IOS, Nexus with NX-OS. No plans to port.

Kind of crazy given that the Nexus doesn't look like much more than C6K++,
and the MDS is the C6K repurposed.

Oh well. Once the Nexus supports MPLS, maybe we'll start voting with our
wallets. That's really the only language Cisco listens to.

Tim:>

From mat_cameron at msn.com  Wed Sep 16 22:13:11 2009
From: mat_cameron at msn.com (Mat Cameron)
Date: Thu, 17 Sep 2009 03:13:11 +0100
Subject: [c-nsp] Inter-As Multicast VPNs
Message-ID: <COL117-W375293A557355D5F85CE8B9BE10@phx.gbl>


Hi

I am running with a project at the moment with regards to getting Inter-AS mvpns working ALL hardware is Cisco. If I read all the material correctly and I would like some clarification, I cannot use non MDT SAFI capable router as Route-Reflectors, as type 2 RDs are non-transitive. The challenge I have is that nearly all my PEs are non MDT SAFi capable,
although I can implement MDT SAFI capable Route-Reflectors. So with that prospect does anyone see me having a problem implementing MDT SAFI capable RRs with non MDT SAFI capable PEs and using Cisco's "MVPN Inter-AS Support Option C"
 
Thanks in advance
 
Mat
_________________________________________________________________
Save time by using Hotmail to access your other email accounts.
http://clk.atdmt.com/UKM/go/167688463/direct/01/

From brett at looney.id.au  Wed Sep 16 23:32:35 2009
From: brett at looney.id.au (Brett Looney)
Date: Thu, 17 Sep 2009 11:32:35 +0800
Subject: [c-nsp] Cisco 2600 and ISDN
In-Reply-To: <C6D53028.4A2E%cisco@peakpeak.com>
References: <C6D53028.4A2E%cisco@peakpeak.com>
Message-ID: <001e01ca3747$8aebdf00$a0c39d00$@id.au>

> I have a central side 2600 with an ISDN BRI card in it, and a remote site
> with a 2600 and ISDN BRI card in it.  I have the ISDN lines working, and I
> have the remote site calling into the central site (I can see the calls on
> the console) and RADIUS appears to be authenticating the call.  Then the
> session drops with this:
<snip>

Unsure what IOS version you're running, but you might try using the "ppp
authorization" command in your dialer interfaces. "debug ppp author" will
also help there. From your debug output, authentication is working but a few
years back the PPP code change to require authorisation whereas before that
random point it didn't really care...

B.


From koug at intracom.gr  Thu Sep 17 03:10:17 2009
From: koug at intracom.gr (John Kougoulos)
Date: Thu, 17 Sep 2009 10:10:17 +0300 (GTB Daylight Time)
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
 ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <0E0ADFB3-3D29-4857-B6B4-92E8698B026E@hughes.com.au>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
	<373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>
	<CD0195AB-DF6F-4B41-83BD-0E6F5F0BADF9@puck.nether.net>
	<20090914143623.GE1508@greenie.muc.de>
	<20090914163011.GC25690@lboro.ac.uk>
	<20090916080639.GX1508@greenie.muc.de>
	<0E0ADFB3-3D29-4857-B6B4-92E8698B026E@hughes.com.au>
Message-ID: <alpine.WNT.2.00.0909171006020.3984@pckoug1.intranet.gr>



On Thu, 17 Sep 2009, David Hughes wrote:

>
> On 16/09/2009, at 6:06 PM, Gert Doering wrote:
>
>> Just imagine how much functionality NX-OS could get if they would stop
>> wasting effort on 17 different software trains for "classic IOS" and
>> instead focus on getting NX-OS on all hardware platforms, and getting
>> feature parity for it.
>
> Totally agree.  It looks like NX-OS has the sort of architecture we all want. 
> And it works.  And its reliable (MDS has been solid).  And its getting 
> features quite quickly.  NX-OS on Cat6k and ASR?  Why not?  Other than BU 
> politics naturally.
>
>

On the other hand, do you remember how long did it take to run native IOS 
on 65xx with the majority (not all) of the CatOS features?

John

From md at bts.sk  Thu Sep 17 02:38:22 2009
From: md at bts.sk (Marian =?utf-8?B?xI51cmtvdmnEjQ==?=)
Date: Thu, 17 Sep 2009 08:38:22 +0200
Subject: [c-nsp] "Enhanced" download procedure
Message-ID: <20090917063822.GA27728@bts.sk>

Rodney Dunn wrote:
> 
> Please check the email thread a week or so back where I gave the direct 
> contacts for feedback.
> 
> They are open and want to hear helpful constructive feedback.
> 
> Rodney

Helpful & constructive feedback ?!

I lost quite some time yesterday just to find out, that this "enhanced"
download is totally broken on Unix OS and despite all the navigation
through the directories it always creates filenames in my home directory
containing backslashes in them. I.e. instead of saving the file to
directory tmp, it creates a filename "tmp\ios...." in my home directory.

And, during the download it kept displaying that my download speed is
56 kb/s while the real speed was orders of magnitude higher.

Is there no longer any quality control in Cisco ? How such crap, which is
apparently unable to do basic things properly, could ever enter production
state and affect downloads for all users of Cisco equipment ?!

And yes, I'm also *seriously* worried about requirement for java support
just to download files - moreover with unrestricted access to the filesystem.
 

   With kind regards,

     M.

From nasir.shaikh at bt.com  Thu Sep 17 03:40:51 2009
From: nasir.shaikh at bt.com (nasir.shaikh at bt.com)
Date: Thu, 17 Sep 2009 08:40:51 +0100
Subject: [c-nsp] 6506-E moving from sup2 to sup32
Message-ID: <D312CD05C8083447B01F57DCDECCF60002675FA0@E03MVZ4-UKDY.domain1.systemhost.net>

Hi,

I am upgrading from sup2a to sup32 on a 6506-E remotely. I know that 2 different sups are not supported but would the chassis running with sup2a recognize a sup32 when inserted? Makes the upgrade much easier.

Appreciate any experiences in this regard

Nasir Shaikh 
| Senior Consultant | BT | Global Professional Services | Mob: +31 (0) 6 5463 5005
BT Meetme 0800 0200768 -Participants code:436 438 14# | E: nasir.shaikh at bt.com | http://www.bt.com/consultingHYPERLINK "http://www.bt.com/consulting"
This email contains information from BT Nederland N.V., which may be privileged or confidential. 
It's meant only for the individual(s) or entity named above. If you are not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited.  
If you have received this email in error, please let me know immediately on the email address above.
We monitor our systems, and may record your emails.

BT Nederland N.V. 
Registered office:  Offices Minerva and Mercurius, Herikerbergweg 2, 1101 CM Amsterdam
Registered at the Amsterdam Chamber of Commerce no:  33296214




From nasir.shaikh at bt.com  Thu Sep 17 06:50:10 2009
From: nasir.shaikh at bt.com (nasir.shaikh at bt.com)
Date: Thu, 17 Sep 2009 11:50:10 +0100
Subject: [c-nsp] 6500 - sup2a to sup32 upgrade
In-Reply-To: <C65AE978.5439%graham@g-rock.net>
Message-ID: <D312CD05C8083447B01F57DCDECCF600026F9091@E03MVZ4-UKDY.domain1.systemhost.net>

 
Hi,

I am upgrading from sup2a to sup32 on a 6506-E remotely. I know that 2
different sups are not supported but would the chassis running with
sup2a recognize a sup32 when inserted? Makes the upgrade much easier.

Appreciate any experiences in this regard

Nasir 

From mtinka at globaltransit.net  Thu Sep 17 06:24:12 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Thu, 17 Sep 2009 18:24:12 +0800
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <20090917063822.GA27728@bts.sk>
References: <20090917063822.GA27728@bts.sk>
Message-ID: <200909171824.13365.mtinka@globaltransit.net>

On Thursday 17 September 2009 02:38:22 pm Marian ?urkovi? 
wrote:

> I lost quite some time yesterday just to find out, that
> this "enhanced" download is totally broken on Unix OS and
> despite all the navigation through the directories it
> always creates filenames in my home directory containing
> backslashes in them. I.e. instead of saving the file to
> directory tmp, it creates a filename "tmp\ios...." in my
> home directory.

I found this strange too, the first time I used it. It took 
me nearly 10 minutes just to find the file after I'd 
downloaded it.

Thank God for Spotlight...

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090917/075f3c5d/attachment.bin>

From achatz at forthnet.gr  Thu Sep 17 07:47:56 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Thu, 17 Sep 2009 14:47:56 +0300
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <200909171824.13365.mtinka@globaltransit.net>
References: <20090917063822.GA27728@bts.sk>
	<200909171824.13365.mtinka@globaltransit.net>
Message-ID: <4AB221EC.2000309@forthnet.gr>

 From http://www.cisco.com/web/Downloads/SDS/Software_Downloads/FAQs.html#faq23

Q. The software file seems to download, but I cannot find it. What do I do?

A.  If you are using a Unix based system such as a MAC, we have a known issue. The file name is getting prefixed with 
the folder name. E.g - if you downloaded the file 'xyz.bin' to a folder 'abc', the file name in the Unix directory will 
be 'abc\xyz.bin'. The file is fine to download. Please rename the file to remove the folder prefix 'abc\' before using 
the file. We are currently working on resolving this issue.

--
Tassos

Mark Tinka wrote on 17/09/2009 13:24:
> On Thursday 17 September 2009 02:38:22 pm Marian ?urkovi? 
> wrote:
> 
>> I lost quite some time yesterday just to find out, that
>> this "enhanced" download is totally broken on Unix OS and
>> despite all the navigation through the directories it
>> always creates filenames in my home directory containing
>> backslashes in them. I.e. instead of saving the file to
>> directory tmp, it creates a filename "tmp\ios...." in my
>> home directory.
> 
> I found this strange too, the first time I used it. It took 
> me nearly 10 minutes just to find the file after I'd 
> downloaded it.
> 
> Thank God for Spotlight...
> 
> Mark.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From jared at puck.nether.net  Thu Sep 17 08:12:22 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 17 Sep 2009 08:12:22 -0400
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AB221EC.2000309@forthnet.gr>
References: <20090917063822.GA27728@bts.sk>
	<200909171824.13365.mtinka@globaltransit.net>
	<4AB221EC.2000309@forthnet.gr>
Message-ID: <5229AB50-0FBB-4D4E-B459-6B4B43F6041C@puck.nether.net>

I hope everyone is engaging your account team and support orgs on this.

This download process is not acceptable, we still need the ability to  
get at the direct link for images to stage them to a UNIX host in "the  
cloud".

I can not be placed in a position of supporting my network from a  
hotel that requires me to re-upload an image over whatever slow- 
congested link I happen to have available.

	- Jared

On Sep 17, 2009, at 7:47 AM, Tassos Chatzithomaoglou wrote:

> From http://www.cisco.com/web/Downloads/SDS/Software_Downloads/FAQs.html#faq23
>
> Q. The software file seems to download, but I cannot find it. What  
> do I do?
>
> A.  If you are using a Unix based system such as a MAC, we have a  
> known issue. The file name is getting prefixed with the folder name.  
> E.g - if you downloaded the file 'xyz.bin' to a folder 'abc', the  
> file name in the Unix directory will be 'abc\xyz.bin'. The file is  
> fine to download. Please rename the file to remove the folder prefix  
> 'abc\' before using the file. We are currently working on resolving  
> this issue.
>
> --
> Tassos
>
> Mark Tinka wrote on 17/09/2009 13:24:
>> On Thursday 17 September 2009 02:38:22 pm Marian ?urkovi? wrote:
>>> I lost quite some time yesterday just to find out, that
>>> this "enhanced" download is totally broken on Unix OS and
>>> despite all the navigation through the directories it
>>> always creates filenames in my home directory containing
>>> backslashes in them. I.e. instead of saving the file to
>>> directory tmp, it creates a filename "tmp\ios...." in my
>>> home directory.
>> I found this strange too, the first time I used it. It took me  
>> nearly 10 minutes just to find the file after I'd downloaded it.
>> Thank God for Spotlight...
>> Mark.
>> ------------------------------------------------------------------------
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From nick at inex.ie  Thu Sep 17 08:20:42 2009
From: nick at inex.ie (Nick Hilliard)
Date: Thu, 17 Sep 2009 13:20:42 +0100
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AB221EC.2000309@forthnet.gr>
References: <20090917063822.GA27728@bts.sk>	<200909171824.13365.mtinka@globaltransit.net>
	<4AB221EC.2000309@forthnet.gr>
Message-ID: <4AB2299A.40803@inex.ie>

On 17/09/2009 12:47, Tassos Chatzithomaoglou wrote:
> A. If you are using a Unix based system such as a MAC, we have a known
> issue. The file name is getting prefixed with the folder name. E.g - if
> you downloaded the file 'xyz.bin' to a folder 'abc', the file name in
> the Unix directory will be 'abc\xyz.bin'. The file is fine to download.
> Please rename the file to remove the folder prefix 'abc\' before using
> the file. We are currently working on resolving this issue.

the fix is to replace "\" with 'file.separator' in pathnames.  It's in 
java.io.File.  Not hard stuff, this - I've never written a line of Java in 
my life, but it only took me about 90 seconds on google to find this out. 
Didn't anyone actually test this product before it shipped?

I also got hit with this problem in the last couple of days after trying to 
download a new software image, and had a moment of overwhelming facepalm 
when I realised what it was doing.

For the record, it took just over 5 minutes and about 30 mouse clicks to 
find the software image I was looking for, starting off from the home page. 
  Once it started downloading, the rate meter was mostly pegged on 
189kB/sec, but would imperceptibly flick between 189 to 383 and then back 
to 189 again.  Was the person who coded this poached from Microsoft? 
http://xkcd.com/612/

I read the FAQ URL with irony

http://www.cisco.com/web/Downloads/SDS/Software_Downloads/FAQs.html#faq22

> Q. Why did you remove the IOS Upgrade planner?
>
> A. The IOS Upgrade Planner was recently retired as part of a Cisco
> support initiative.  The Download Software area supports all Cisco IOS
> software.  This is one of many enhancements designed to streamline your
> software download process and make it easier to find IOS Software for
> your Cisco products.

Please can we have the old IOS upgrade planner back?  Pretty please?

And if not, can someone please tell Cisco that the Java downloader is 
teeth-grindingly awful.  There are primitives in browsers for downloading. 
  Please use them instead, instead of reinventing the wheel and ending up 
with a square axle.

Nick

From achatz at forthnet.gr  Thu Sep 17 08:29:55 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Thu, 17 Sep 2009 15:29:55 +0300
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <5229AB50-0FBB-4D4E-B459-6B4B43F6041C@puck.nether.net>
References: <20090917063822.GA27728@bts.sk>
	<200909171824.13365.mtinka@globaltransit.net>
	<4AB221EC.2000309@forthnet.gr>
	<5229AB50-0FBB-4D4E-B459-6B4B43F6041C@puck.nether.net>
Message-ID: <4AB22BC3.7040803@forthnet.gr>

I have already given feedback quite a few times regarding my download experience (generally i don't like the idea of 
"using" my account team for obvious things).

I welcome this new kind of downloader, but as i have wondered back then 
(http://marc.info/?l=cisco-nsp&m=124712980900460&w=2) this should be made optional for all those cli-hardcore users.

--
Tassos

Jared Mauch wrote on 17/09/2009 15:12:
> I hope everyone is engaging your account team and support orgs on this.
> 
> This download process is not acceptable, we still need the ability to 
> get at the direct link for images to stage them to a UNIX host in "the 
> cloud".
> 
> I can not be placed in a position of supporting my network from a hotel 
> that requires me to re-upload an image over whatever slow-congested link 
> I happen to have available.
> 
>     - Jared
> 
> On Sep 17, 2009, at 7:47 AM, Tassos Chatzithomaoglou wrote:
> 
>> From 
>> http://www.cisco.com/web/Downloads/SDS/Software_Downloads/FAQs.html#faq23
>>
>> Q. The software file seems to download, but I cannot find it. What do 
>> I do?
>>
>> A.  If you are using a Unix based system such as a MAC, we have a 
>> known issue. The file name is getting prefixed with the folder name. 
>> E.g - if you downloaded the file 'xyz.bin' to a folder 'abc', the file 
>> name in the Unix directory will be 'abc\xyz.bin'. The file is fine to 
>> download. Please rename the file to remove the folder prefix 'abc\' 
>> before using the file. We are currently working on resolving this issue.
>>
>> -- 
>> Tassos
>>
>> Mark Tinka wrote on 17/09/2009 13:24:
>>> On Thursday 17 September 2009 02:38:22 pm Marian ?urkovi? wrote:
>>>> I lost quite some time yesterday just to find out, that
>>>> this "enhanced" download is totally broken on Unix OS and
>>>> despite all the navigation through the directories it
>>>> always creates filenames in my home directory containing
>>>> backslashes in them. I.e. instead of saving the file to
>>>> directory tmp, it creates a filename "tmp\ios...." in my
>>>> home directory.
>>> I found this strange too, the first time I used it. It took me nearly 
>>> 10 minutes just to find the file after I'd downloaded it.
>>> Thank God for Spotlight...
>>> Mark.
>>> ------------------------------------------------------------------------
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 

From achatz at forthnet.gr  Thu Sep 17 08:36:33 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Thu, 17 Sep 2009 15:36:33 +0300
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AB2299A.40803@inex.ie>
References: <20090917063822.GA27728@bts.sk>	<200909171824.13365.mtinka@globaltransit.net>	<4AB221EC.2000309@forthnet.gr>
	<4AB2299A.40803@inex.ie>
Message-ID: <4AB22D51.3060207@forthnet.gr>



Nick Hilliard wrote on 17/09/2009 15:20:

> 
> For the record, it took just over 5 minutes and about 30 mouse clicks to 
> find the software image I was looking for, starting off from the home 
> page.  Once it started downloading, the rate meter was mostly pegged on 
> 189kB/sec, but would imperceptibly flick between 189 to 383 and then 
> back to 189 again.  Was the person who coded this poached from 
> Microsoft? http://xkcd.com/612/
> 

I had exactly the same experience too. To be honest i was hoping Cisco would have atleast coded an applet capable of 
maxing download speed or splitting the file in multiple parts and downloading all of them concurrently.
After all, Cisco is the one that talks about the zettabyte era all the time.

--
Tassos

From eng_mssk at hotmail.com  Thu Sep 17 09:00:09 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Thu, 17 Sep 2009 16:00:09 +0300
Subject: [c-nsp] Graphing specefic traffic
Message-ID: <BLU102-W28B6DAC3DB0E5E42D0C72BFAE10@phx.gbl>


hey all

i have a 7600 cisco router and i have customers terminated to it (ethernet)
for example one of the customers is consuming SIP , i want to be able to graph this traffic (SIP) for that certain user
can i do that ??
no SCE to be used :)

_________________________________________________________________
With Windows Live, you can organize, edit, and share your photos.
http://www.microsoft.com/middleeast/windows/windowslive/products/photo-gallery-edit.aspx

From rdobbins at arbor.net  Thu Sep 17 09:11:08 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Thu, 17 Sep 2009 20:11:08 +0700
Subject: [c-nsp] Graphing specefic traffic
In-Reply-To: <BLU102-W28B6DAC3DB0E5E42D0C72BFAE10@phx.gbl>
References: <BLU102-W28B6DAC3DB0E5E42D0C72BFAE10@phx.gbl>
Message-ID: <C78A4866-F893-4560-99A2-73AB60E41DF0@arbor.net>


On Sep 17, 2009, at 8:00 PM, Mohammad Khalil wrote:

> no SCE to be used :)

Get a router which has non-broken NetFlow, like an ASR1K, or a GSR, or  
CRS-1, and put it southbound of your 7600.

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

Sorry, sometimes I mistake your existential crises for technical
insights.

			-- xkcd #625


From jmaimon at ttec.com  Thu Sep 17 09:08:49 2009
From: jmaimon at ttec.com (Joe Maimon)
Date: Thu, 17 Sep 2009 09:08:49 -0400
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AAFD139.4050402@west.net>
References: <4AAFD139.4050402@west.net>
Message-ID: <4AB234E1.30108@ttec.com>

Jay Hennigan wrote:
> What the #$^&$@# is going on with Cisco's download site?  It completely 
> hangs Firefox with some shopping cart java thing.  And this is downright 
> scary:  http://www.west.net/~jay/images/cisco-wants-root.png
> 
> Enhanced downloads, brought to you by the same people who brought us 
> enhanced interrogation?
> 
> Is there a workaround?  What happened to our friend kobayashi ?
> 

Yes, there is a workaround. Put a windows server somewhere with good 
bandwidth, use modern browsers and java to download the file, place it 
into a TFTP/FTP/HTTP served up from there and now you are good to go, 
with just this short little detour.

There are some concepts that web monkeys dont grasp very well, such as:

If it aint broke, dont fix it.
Throwing the baby out with the bathwater.
Reinventing the wheel, badly.

It is not cisco specific, but they do seem to go through this every 
couple years. Half of google searches for cisco documentation land you 
on a cisco page that doesnt exist anymore and doesnt redirect anywhere 
you want to go.

This wouldnt be such a problem if folks in the know could use nice 
standardized methods such as FTP or lynx compatible HTTP to download 
what they want, regardless of which download method of the day is 
currently in effect.

As it happens, I would venture to say that most utilizations of cisco 
downloads are by people in the know.

This bulk/batch downloader does have its upsides, but without any decent 
alternative readily available, you are stuck with its considerable 
downsides, some of which can be coded around and some which just plain cant.

Perhaps cisco is trying to address a perceived problem with getting 
people who may not be in the know to do security updates.

I would suggest that they focus on methods that would allow a download 
and upgrade direct from the console of the equipment in question.

Perhaps the larger issue is the terminology shift - "Shopping Cart" 
implies purchasing.

Joe

From avayner at cisco.com  Thu Sep 17 09:40:01 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Thu, 17 Sep 2009 15:40:01 +0200
Subject: [c-nsp] Graphing specefic traffic
In-Reply-To: <BLU102-W28B6DAC3DB0E5E42D0C72BFAE10@phx.gbl>
References: <BLU102-W28B6DAC3DB0E5E42D0C72BFAE10@phx.gbl>
Message-ID: <FDD1CDB3FB499E4087CC7670BBCA22C6446DF5@XMB-AMS-101.cisco.com>

Mohammad,

Is this for long term reporting or for short term troubleshooting?

Thanks
Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mohammad Khalil
Sent: Thursday, September 17, 2009 16:00
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Graphing specefic traffic


hey all

i have a 7600 cisco router and i have customers terminated to it
(ethernet)
for example one of the customers is consuming SIP , i want to be able to
graph this traffic (SIP) for that certain user
can i do that ??
no SCE to be used :)

_________________________________________________________________
With Windows Live, you can organize, edit, and share your photos.
http://www.microsoft.com/middleeast/windows/windowslive/products/photo-g
allery-edit.aspx
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From A.L.M.Buxey at lboro.ac.uk  Thu Sep 17 10:14:54 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Thu, 17 Sep 2009 15:14:54 +0100
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AB234E1.30108@ttec.com>
References: <4AAFD139.4050402@west.net> <4AB234E1.30108@ttec.com>
Message-ID: <20090917141454.GD12555@lboro.ac.uk>

hi,

"Your New Software Download Experience"

its an experience alright. I'll give them that.

just not a good one :-(


alan

From rjs at eng.gxn.net  Thu Sep 17 10:34:18 2009
From: rjs at eng.gxn.net (Rob Shakir)
Date: Thu, 17 Sep 2009 15:34:18 +0100
Subject: [c-nsp] MPLS TE Fast Re-route
In-Reply-To: <7EA99F102607DF43BDF25CC68475008703DDDE35@lhmail.btinet.local>
References: <7EA99F102607DF43BDF25CC68475008703DDDE35@lhmail.btinet.local>
Message-ID: <20090917143417.GE5351@cappuccino.rob.sh>

On Tue, Sep 15, 2009 at 12:25:36AM +0100, Charlie Greenaway wrote:
> Hi,
> 
> I have a question on MPLS TE and Fast Re-Route.
> 
> I have a test network and I want to check that the behaviour I am seeing is correct.
> 
> When you set-up an backup path for patch-protection, it would seem that RSVP
> sends signalling messages down the backup path to reserve the bandwidth.
> However, it does not seem to build an LSP and assign labels to it until the
> primary path breaks.  Is this correct?  Has anyone got any advice on using
> MPLS FRR?

Hi Charlie,

What's the platform that your test network is based on? I don't think that what
you're seeing is the intended behaviour, if you have properly functioning FRR.

Looking at as 12410 running 12.0(32)S13, we see that the LFIB does show some
labels for the FRR paths, in both cases. Where my device has built an NNHOP
tunnel (via auto-tunnel), in 'sh mpls traffic-eng fast-reroute database' there
is a new label assigned:

Prefix             Tunnel     In-label Out intf/label   FRR intf/label   Status
10.0.0.0/30 Tu1334     200      PO4/0:Untagged   Tu65464:339      ready  

Looking at label 339:

12410>sh mpls forwarding-table labels 339
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface              
339    3783        x.y.z.a 65455 [4653] 0          Gi1/1.5    a.b.c.d

i.e. there is a label assigned for this re-route, and it has a forwarding table
entry. The same thing is true for any manually configured backup tunnels.

Within your topology, are you running path protection? (I'm not sure whether
your 'patch protection' is a typo). I would still assume that in this case there
is a requirement to have a configured LSP to switch to for protection, the
assumption that one can signal and establish a new LSP within the intended
timeframe for FRR is somewhat flawed.

On your test PE that has configured protection for a tunnel, when you run 'sh
mpls traffic-eng tunnels tu<x> protect' for the tunnel, does the device think
that it has an active FRR path to re-route to (as per the below)?

12410>sh mpls traffic-eng tunnels tu1121 prot | i Fast Rero|Backup Tu|Out
  Fast Reroute Protection: Requested
    Outbound: FRR Ready
      Backup Tu5129 to LSP nhop

If not -- I'd suggest that the device hasn't properly signalled for a FRR path
for the tunnel.

To verify this, can you see a reservation for the tunnel on all the midpoints
for the tunnel? When the label is returned from a P node to a PE, the RRO object
that is returned should contain the label that is expected once the FRR label
has been popped. If the reservation has been made succesfully, the LSP labes are
assigned, and should be in the LFIB throughout the tunnel's path.

One gotcha that we've seen with FRR is platforms that run SSO are incapable of
running auto-tunnel backup (and hence won't let you configure it), this seems to
get to the stage that the device works out that there is no FRR path, and then
tries to configure it, and silently fail. The 'sh mpls tra tu tu<x> prot' then
show something akin to the below:

  Fast Reroute Protection: Requested
    Outbound: Unprotected: no backup tunnel assigned

I'm not sure what FRR advice you'd like, but feel free to ping me a mail on/off
list if you think there's anything I can assist with.

Kind regards,
Rob

-- 
Rob Shakir                      <rjs at eng.gxn.net>
Network Development Engineer    GX Networks/Vialtus Solutions
ddi: +44208 587 6077            mob: +44797 155 4098
pgp: 0xc07e6deb                 nic-hdl: RJS-RIPE

This email is subject to: http//www.vialtus.com/disclaimer.html


From SPfister at dps.k12.oh.us  Thu Sep 17 10:39:21 2009
From: SPfister at dps.k12.oh.us (Steven Pfister)
Date: Thu, 17 Sep 2009 10:39:21 -0400
Subject: [c-nsp] Need help troubleshooting CRC errors
Message-ID: <4AB211D9.9E6F.00B8.0@dps.k12.oh.us>

Some of our older remote sites are connected via ATM. Two or three T1s come into an Cisco 8510, and from there a 155mbps OC3 connection over fiber to a 3640 router. Lately, I've been noticing that pretty much every one of them is showing what I think is a rather high receive error count on the 3640 end of the OC3 connection, and it all seems to be CRC errors. Not much of any errors are showing up on the 8510 end of the OC3 connection. For example, one site yesterday late afternoon showed 63, 763 receive errors for the day. Several others were in the 20Ks. I'm not really certain what the cause might be, or where to start. Can anyone help?

Thanks!


Steve Pfister
Technical Coordinator, 
The Office of Information Technology
Dayton Public Schools
115 S. Ludlow St. 
Dayton, OH 45402
 
Office (937) 542-3149
Cell (937) 673-6779
Direct Connect: 137*131747*8
Email spfister at dps.k12.oh.us



From amsoares at netcabo.pt  Thu Sep 17 11:45:43 2009
From: amsoares at netcabo.pt (Antonio Soares)
Date: Thu, 17 Sep 2009 16:45:43 +0100
Subject: [c-nsp] Need help troubleshooting CRC errors
In-Reply-To: <4AB211D9.9E6F.00B8.0@dps.k12.oh.us>
References: <4AB211D9.9E6F.00B8.0@dps.k12.oh.us>
Message-ID: <436848D1ED9646638E260E7AE456D593@int.convex.pt>

Try this document:

CRC Troubleshooting Guide for ATM Interfaces

http://www.cisco.com/en/US/tech/tk39/tk48/technologies_tech_note09186a00800c93ef.shtml 


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Steven Pfister
Sent: quinta-feira, 17 de Setembro de 2009 15:39
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Need help troubleshooting CRC errors

Some of our older remote sites are connected via ATM. Two or three T1s come into an Cisco 8510, and from there a 155mbps OC3
connection over fiber to a 3640 router. Lately, I've been noticing that pretty much every one of them is showing what I think is a
rather high receive error count on the 3640 end of the OC3 connection, and it all seems to be CRC errors. Not much of any errors are
showing up on the 8510 end of the OC3 connection. For example, one site yesterday late afternoon showed 63, 763 receive errors for
the day. Several others were in the 20Ks. I'm not really certain what the cause might be, or where to start. Can anyone help?

Thanks!


Steve Pfister
Technical Coordinator,
The Office of Information Technology
Dayton Public Schools
115 S. Ludlow St. 
Dayton, OH 45402
 
Office (937) 542-3149
Cell (937) 673-6779
Direct Connect: 137*131747*8
Email spfister at dps.k12.oh.us


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



From eng_mssk at hotmail.com  Thu Sep 17 11:57:50 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Thu, 17 Sep 2009 18:57:50 +0300
Subject: [c-nsp] Graphing specefic traffic
In-Reply-To: <FDD1CDB3FB499E4087CC7670BBCA22C6446DF5@XMB-AMS-101.cisco.com>
References: <BLU102-W28B6DAC3DB0E5E42D0C72BFAE10@phx.gbl>
	<FDD1CDB3FB499E4087CC7670BBCA22C6446DF5@XMB-AMS-101.cisco.com>
Message-ID: <BLU102-W2927BD80F06C370B2A1AE4FAE10@phx.gbl>


No Arie its a short term but it would be useful if it can be done on the long term

> Subject: RE: [c-nsp] Graphing specefic traffic
> Date: Thu, 17 Sep 2009 15:40:01 +0200
> From: avayner at cisco.com
> To: eng_mssk at hotmail.com; cisco-nsp at puck.nether.net
> 
> Mohammad,
> 
> Is this for long term reporting or for short term troubleshooting?
> 
> Thanks
> Arie
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mohammad Khalil
> Sent: Thursday, September 17, 2009 16:00
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Graphing specefic traffic
> 
> 
> hey all
> 
> i have a 7600 cisco router and i have customers terminated to it
> (ethernet)
> for example one of the customers is consuming SIP , i want to be able to
> graph this traffic (SIP) for that certain user
> can i do that ??
> no SCE to be used :)
> 
> _________________________________________________________________
> With Windows Live, you can organize, edit, and share your photos.
> http://www.microsoft.com/middleeast/windows/windowslive/products/photo-g
> allery-edit.aspx
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_________________________________________________________________
Show them the way! Add maps and directions to your party invites. 
http://www.microsoft.com/windows/windowslive/products/events.aspx

From elmi at 4ever.de  Thu Sep 17 11:21:46 2009
From: elmi at 4ever.de (Elmar K. Bins)
Date: Thu, 17 Sep 2009 17:21:46 +0200
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AB234E1.30108@ttec.com>
References: <4AAFD139.4050402@west.net> <4AB234E1.30108@ttec.com>
Message-ID: <20090917152146.GR43828@ronin.4ever.de>

(Bcc of this goes to our account manager who should start shooting at
 Cisco webmonkey headquarters, please)

jmaimon at ttec.com (Joe Maimon) wrote:

>> What the #$^&$@# is going on with Cisco's download site?  It completely 
>> hangs Firefox with some shopping cart java thing.  And this is downright 
>> scary:  http://www.west.net/~jay/images/cisco-wants-root.png
>> Enhanced downloads, brought to you by the same people who brought us 
>> enhanced interrogation?
>> Is there a workaround?  What happened to our friend kobayashi ?
> 
> Yes, there is a workaround. Put a windows server somewhere with good 
> bandwidth, use modern browsers and java to download the file, place it into 
> a TFTP/FTP/HTTP served up from there and now you are good to go, with just 
> this short little detour.

Actually, that would be the only thing that helped, but...why would one
want to introduce a windows workstation into the secluded world of the
management network?

This Web stuff might be nice IF one needed the software on their workstation.
Well, I suppose, less than 1% need that. The other 99+% will want to have
the software on the TFTP server they use to feed their infrastructure boxes.

Honestly, web interfaces suck for this, but

  - introducing Java crap
  - that also wants extended privileges on the box it runs on
  - and is buggy

...my ass - what happened to Cisco being network-centric?

Oh, btw - "modern browsers" - I wouldn't call Opera 10 old-fashioned, but
the Cisco site just dropped me an error message about "my cart".

Iron worked, but...

Just to remind the Cisco people: Your website may be flashy as hell,
because Management looks at it. Downloading MUST NOT BE FLASHY, because
it's being used from the dark recesses of datacenters with very often
no graphical browser.

CISCO - LEARN!

In the future, I might ask my account manager to get the software, put
it on a stick and send it to me.


> This bulk/batch downloader does have its upsides, but without any decent 
> alternative readily available, you are stuck with its considerable 
> downsides, some of which can be coded around and some which just plain 
> cant.

That downloader has no upsides at all, because honestly - why would you
want the software on your workstation?

> I would suggest that they focus on methods that would allow a download and 
> upgrade direct from the console of the equipment in question.

Very definitely what we need.

> Perhaps the larger issue is the terminology shift - "Shopping Cart" implies 
> purchasing.

Which only means that they have bought a shop software and are now trying
it out on unsuspecting networkers who need (!!!) the software and will have
(!!!) to jump through all the hoops to get it.

This sucks, and I bet most of the Cisco folks know it.

Elmar.



From paul at paulstewart.org  Thu Sep 17 13:36:25 2009
From: paul at paulstewart.org (Paul Stewart)
Date: Thu, 17 Sep 2009 13:36:25 -0400
Subject: [c-nsp] QOS Problem - T1 Interface
Message-ID: <003a01ca37bd$61ff2c20$25fd8460$@org>

Hi folks...

 

I need a second set of eyes here...;)  We have a customer fed off T1 to an
Adtran router that is having problems with their voice quality... they also
share this as their Internet connection.

 

A ticket is open with Adtran to confirm their QOS settings but I'm hoping to
clarify if below is correct? ;)  

 

At the moment I'm capturing this, they have no active voice calls....

 

interface Serial6/0/3:0

 description xxxxxxxxxxxxxxxxxxxxxxxxxx

 ip address xx.xx.xx.xx 255.255.255.248

 ip nbar protocol-discovery

 encapsulation ppp

 no fair-queue

 service-policy output KGCC

 

 

class-map match-all VOIP-Control

  match protocol mgcp

class-map match-all VOIP-Voice

  match protocol rtp

 

policy-map KGCC

  class VOIP-Control

    bandwidth 200

  class VOIP-Voice

    priority 700

  class class-default

    fair-queue

 

 

dis1-rtr-pt#sh policy-map interface Serial 6/0/3:0

 Serial6/0/3:0

 

  Service-policy output: KGCC

 

    queue stats for all priority classes:

 

      queue limit 175 (packets)

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts queued/bytes queued) 7427340/1512404672

 

    Class-map: VOIP-Control (match-all)

      42117 packets, 19965187 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: protocol mgcp

      Queueing

      queue limit 50 (packets)

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts queued/bytes queued) 42117/19965187

      bandwidth 200 kbps

 

    Class-map: VOIP-Voice (match-all)

      7427340 packets, 1512404672 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: protocol rtp

      Priority:  700 kbps, burst 17500 (bytes)

 

    Class-map: class-default (match-any)

      27560986 packets, 19263245303 bytes

      5 minute offered rate 520000 bps, drop rate 0 bps

      Match: any

      Queueing

      queue limit 159 (packets)

      (queue depth/total drops/no-buffer drops/flowdrops) 0/47180/0/47180

      (pkts queued/bytes queued) 27637553/19244765795

      Fair-queue: per-flow queue limit 39

 

 

Thanks,

 

Paul

 


From benny+usenet at amorsen.dk  Thu Sep 17 12:53:11 2009
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Thu, 17 Sep 2009 18:53:11 +0200
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AB22D51.3060207@forthnet.gr> (Tassos Chatzithomaoglou's message
	of "Thu, 17 Sep 2009 15:36:33 +0300")
References: <20090917063822.GA27728@bts.sk>
	<200909171824.13365.mtinka@globaltransit.net>
	<4AB221EC.2000309@forthnet.gr> <4AB2299A.40803@inex.ie>
	<4AB22D51.3060207@forthnet.gr>
Message-ID: <m33a6lh5s8.fsf@ursa.amorsen.dk>

Tassos Chatzithomaoglou <achatz at forthnet.gr> writes:

> I had exactly the same experience too. To be honest i was hoping Cisco
> would have atleast coded an applet capable of maxing download speed or
> splitting the file in multiple parts and downloading all of them
> concurrently.

If that improves speed, either your network or your network stack is
broken, or you're simply grabbing extra bandwidth to the detriment of
others on the same network. In the last case the network administrators
ought to use a more fair queueing algorithm.

Either way, it would seem silly for Cisco to support such a thing.


/Benny


From achatz at forthnet.gr  Thu Sep 17 14:23:03 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Thu, 17 Sep 2009 21:23:03 +0300
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <m33a6lh5s8.fsf@ursa.amorsen.dk>
References: <20090917063822.GA27728@bts.sk>	<200909171824.13365.mtinka@globaltransit.net>	<4AB221EC.2000309@forthnet.gr>
	<4AB2299A.40803@inex.ie>	<4AB22D51.3060207@forthnet.gr>
	<m33a6lh5s8.fsf@ursa.amorsen.dk>
Message-ID: <4AB27E87.9020802@forthnet.gr>

There are a lot of factors that can influence your max download speed.
Instead of messing with TCP window parameters for a >200ms distance, i would prefer to 
open multiple connections for a small timeframe.
After all, i'm not going to download hundreds of images. I just need max speed for a few 
minutes...from anywhere.


-- 
Tassos

Benny Amorsen wrote on 17/09/2009 19:53:
> Tassos Chatzithomaoglou <achatz at forthnet.gr> writes:
> 
>> I had exactly the same experience too. To be honest i was hoping Cisco
>> would have atleast coded an applet capable of maxing download speed or
>> splitting the file in multiple parts and downloading all of them
>> concurrently.
> 
> If that improves speed, either your network or your network stack is
> broken, or you're simply grabbing extra bandwidth to the detriment of
> others on the same network. In the last case the network administrators
> ought to use a more fair queueing algorithm.
> 
> Either way, it would seem silly for Cisco to support such a thing.
> 
> 
> /Benny
> 
> 


From frnkblk at iname.com  Thu Sep 17 14:24:05 2009
From: frnkblk at iname.com (Frank Bulk)
Date: Thu, 17 Sep 2009 13:24:05 -0500
Subject: [c-nsp] 2950 issues - Link comes UP only after reboot - Wimax
In-Reply-To: <7db92dcc0909160013t3cd5dfeey3c18417bffc32a79@mail.gmail.com>
References: <7db92dcc0909160013t3cd5dfeey3c18417bffc32a79@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAB2vN5FWhqaTaPvlR6CG6BvAQAAAAA=@iname.com>

Did it go into err-disable?

Frank

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ved Labs
Sent: Wednesday, September 16, 2009 2:14 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] 2950 issues - Link comes UP only after reboot - Wimax

Observing starnge problem in WS-C2950G-24-EI switches.
The link goes down and does not comes up .

Link cames up only , when the switch is rebooted manually.
change patch cord and change Gibic module does not help

UDLD messages are observed . but after the reboot , the switch becomes OK.

Thanks,
Biddu.
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From achatz at forthnet.gr  Thu Sep 17 14:24:17 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Thu, 17 Sep 2009 21:24:17 +0300
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <m33a6lh5s8.fsf@ursa.amorsen.dk>
References: <20090917063822.GA27728@bts.sk>	<200909171824.13365.mtinka@globaltransit.net>	<4AB221EC.2000309@forthnet.gr>
	<4AB2299A.40803@inex.ie>	<4AB22D51.3060207@forthnet.gr>
	<m33a6lh5s8.fsf@ursa.amorsen.dk>
Message-ID: <4AB27ED1.3020207@forthnet.gr>

There are a lot of factors that can influence your max download speed.
Instead of messing with TCP window parameters for a >200ms distance, i would prefer to 
open multiple connections for a small timeframe.
After all, i'm not going to download hundreds of images. I just need max speed for a few 
minutes...from anywhere.


-- 
Tassos

Benny Amorsen wrote on 17/09/2009 19:53:
> Tassos Chatzithomaoglou <achatz at forthnet.gr> writes:
> 
>> I had exactly the same experience too. To be honest i was hoping Cisco
>> would have atleast coded an applet capable of maxing download speed or
>> splitting the file in multiple parts and downloading all of them
>> concurrently.
> 
> If that improves speed, either your network or your network stack is
> broken, or you're simply grabbing extra bandwidth to the detriment of
> others on the same network. In the last case the network administrators
> ought to use a more fair queueing algorithm.
> 
> Either way, it would seem silly for Cisco to support such a thing.
> 
> 
> /Benny
> 
> 


From judah.scott.iam at gmail.com  Thu Sep 17 14:26:42 2009
From: judah.scott.iam at gmail.com (Judah Scott)
Date: Thu, 17 Sep 2009 11:26:42 -0700
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <m33a6lh5s8.fsf@ursa.amorsen.dk>
References: <20090917063822.GA27728@bts.sk>
	<200909171824.13365.mtinka@globaltransit.net>
	<4AB221EC.2000309@forthnet.gr> <4AB2299A.40803@inex.ie>
	<4AB22D51.3060207@forthnet.gr> <m33a6lh5s8.fsf@ursa.amorsen.dk>
Message-ID: <3172b9cb0909171126u267c398ex64c97ab2b520f2f2@mail.gmail.com>

Especially since any respectable download manager can already split files
and download the parts ...

-J Scott

On Thu, Sep 17, 2009 at 9:53 AM, Benny Amorsen
<benny+usenet at amorsen.dk<benny%2Busenet at amorsen.dk>
> wrote:

> Tassos Chatzithomaoglou <achatz at forthnet.gr> writes:
>
> > I had exactly the same experience too. To be honest i was hoping Cisco
> > would have atleast coded an applet capable of maxing download speed or
> > splitting the file in multiple parts and downloading all of them
> > concurrently.
>
> If that improves speed, either your network or your network stack is
> broken, or you're simply grabbing extra bandwidth to the detriment of
> others on the same network. In the last case the network administrators
> ought to use a more fair queueing algorithm.
>
> Either way, it would seem silly for Cisco to support such a thing.
>
>
> /Benny
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From dwcarder at wisc.edu  Thu Sep 17 14:49:53 2009
From: dwcarder at wisc.edu (Dale W. Carder)
Date: Thu, 17 Sep 2009 13:49:53 -0500
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AAFD139.4050402@west.net>
References: <4AAFD139.4050402@west.net>
Message-ID: <54B74A52-F9EC-47DD-92F9-97913A7026D7@wisc.edu>


On Sep 15, 2009, at 12:39 PM, Jay Hennigan wrote:

> What the #$^&$@# is going on with Cisco's download site?  It  
> completely hangs Firefox with some shopping cart java thing.
>
> Is there a workaround?

I found a workaround.  I couldn't download a file due to
some stupid java error, so I opened a tac case for them
to give me the file.

Maybe after this happens enough times and costs them real
money it will get fixed.

Dale


From paul at paulstewart.org  Thu Sep 17 15:20:01 2009
From: paul at paulstewart.org (Paul Stewart)
Date: Thu, 17 Sep 2009 15:20:01 -0400
Subject: [c-nsp] QOS Problem - T1 Interface
In-Reply-To: <003a01ca37bd$61ff2c20$25fd8460$@org>
References: <003a01ca37bd$61ff2c20$25fd8460$@org>
Message-ID: <005101ca37cb$db2f0120$918d0360$@org>

Sorry to bump my own post but we took out NBAR and starting marking based on
source IP block and problem solved.  For some reason (seen this before and
it just struck me) NBAR doesn't always identify traffic properly...

New config that is working *great*...;)

class-map match-any KGCC-QOS
  match access-group 66
policy-map KGCC2
  class KGCC-QOS
    priority 1000 1500


Paul




-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Paul Stewart
Sent: September-17-09 1:36 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] QOS Problem - T1 Interface

Hi folks...

 

I need a second set of eyes here...;)  We have a customer fed off T1 to an
Adtran router that is having problems with their voice quality... they also
share this as their Internet connection.

 

A ticket is open with Adtran to confirm their QOS settings but I'm hoping to
clarify if below is correct? ;)  

 

At the moment I'm capturing this, they have no active voice calls....

 

interface Serial6/0/3:0

 description xxxxxxxxxxxxxxxxxxxxxxxxxx

 ip address xx.xx.xx.xx 255.255.255.248

 ip nbar protocol-discovery

 encapsulation ppp

 no fair-queue

 service-policy output KGCC

 

 

class-map match-all VOIP-Control

  match protocol mgcp

class-map match-all VOIP-Voice

  match protocol rtp

 

policy-map KGCC

  class VOIP-Control

    bandwidth 200

  class VOIP-Voice

    priority 700

  class class-default

    fair-queue

 

 

dis1-rtr-pt#sh policy-map interface Serial 6/0/3:0

 Serial6/0/3:0

 

  Service-policy output: KGCC

 

    queue stats for all priority classes:

 

      queue limit 175 (packets)

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts queued/bytes queued) 7427340/1512404672

 

    Class-map: VOIP-Control (match-all)

      42117 packets, 19965187 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: protocol mgcp

      Queueing

      queue limit 50 (packets)

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts queued/bytes queued) 42117/19965187

      bandwidth 200 kbps

 

    Class-map: VOIP-Voice (match-all)

      7427340 packets, 1512404672 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: protocol rtp

      Priority:  700 kbps, burst 17500 (bytes)

 

    Class-map: class-default (match-any)

      27560986 packets, 19263245303 bytes

      5 minute offered rate 520000 bps, drop rate 0 bps

      Match: any

      Queueing

      queue limit 159 (packets)

      (queue depth/total drops/no-buffer drops/flowdrops) 0/47180/0/47180

      (pkts queued/bytes queued) 27637553/19244765795

      Fair-queue: per-flow queue limit 39

 

 

Thanks,

 

Paul

 

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From kgraham at industrial-marshmallow.com  Thu Sep 17 15:21:57 2009
From: kgraham at industrial-marshmallow.com (Kevin Graham)
Date: Thu, 17 Sep 2009 12:21:57 -0700 (PDT)
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AB234E1.30108@ttec.com>
References: <4AAFD139.4050402@west.net> <4AB234E1.30108@ttec.com>
Message-ID: <580813.25824.qm@web1211.biz.mail.gq1.yahoo.com>



> This wouldnt be such a problem if folks in the know could use nice standardized 
> methods such as FTP or lynx compatible HTTP to download what they want, 
> regardless of which download method of the day is currently in effect.

Indeed. I have several of these odd "network devices" (they don't The Windows or
The Java) that I occasionally need to pull updates from directly from "Cisco"
from. Until last week, in a pinch I could download software images directly, since
it supported "standard protocols" and didn't need a custom application for file
transfers.

> Perhaps cisco is trying to address a perceived problem with getting people who 
> may not be in the know to do security updates.

Wonderful. Perhaps they could address that by providing a user-friendly java app
that could be downloaded via the http server on their devices. This could help
encourage Secure Device Management and include configuration advice as well.

If for some reason that's unpalatable, maybe these updates could be recommended
by devices implementing some kind of Smart Call Home interface.

For "people not in the know", their comfort level might be helped if device had
supported Modularity, so it could be hot-patches without requiring monolithic
updates.

> Perhaps the larger issue is the terminology shift - "Shopping Cart" implies 
> purchasing.

If this needed to be supported, maybe there could be Universal images per
device with a Cisco License Manager and a Software Activation feature.

(Awareness of other internal organizations and interest in providing consistent
solutions is lacking across the board at Cisco and not just specific BU's).


From blocke at newpaltz.edu  Thu Sep 17 15:31:49 2009
From: blocke at newpaltz.edu (Bruce A. Locke)
Date: Thu, 17 Sep 2009 15:31:49 -0400 (EDT)
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AAFE01C.3080602@cisco.com>
Message-ID: <1909324405.1463201253215909975.JavaMail.root@zmail.newpaltz.edu>


----- "Rodney Dunn" <rodunn at cisco.com> wrote:

| Please check the email thread a week or so back where I gave the
| direct contacts for feedback.
| 
| They are open and want to hear helpful constructive feedback.


I've sent them complaints before and filled out their surveys.  And this comes along.  Is it bombing for anyone else on Mac OS X?

Excuse me while I try to relay my constructive criticism through our reseller.


-- 
Bruce A. Locke
blocke at newpaltz.edu
HAB 50 - (845) 257-3809

Network Administrator
Computer Services
State University of New York at New Paltz 


From kgraham at industrial-marshmallow.com  Thu Sep 17 15:46:44 2009
From: kgraham at industrial-marshmallow.com (Kevin Graham)
Date: Thu, 17 Sep 2009 12:46:44 -0700 (PDT)
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <alpine.WNT.2.00.0909171006020.3984@pckoug1.intranet.gr>
References: <200909081035.tcp24@psirt.cisco.com>
	<052CD3D4679F44D096443E70EFE5EBC3@int.convex.pt>
	<20090909203821.GC117@greenie.muc.de> <4AA8E79E.2030109@sara.nl>
	<20090910121617.GH1508@greenie.muc.de>
	<373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>
	<CD0195AB-DF6F-4B41-83BD-0E6F5F0BADF9@puck.nether.net>
	<20090914143623.GE1508@greenie.muc.de>
	<20090914163011.GC25690@lboro.ac.uk>
	<20090916080639.GX1508@greenie.muc.de>
	<0E0ADFB3-3D29-4857-B6B4-92E8698B026E@hughes.com.au>
	<alpine.WNT.2.00.0909171006020.3984@pckoug1.intranet.gr>
Message-ID: <412409.56453.qm@web1206.biz.mail.gq1.yahoo.com>





> On the other hand, do you remember how long did it take to run native IOS on 
> 65xx with the majority (not all) of the CatOS features?

Considering "IOS Feature Parity" was an SXI objective, quite a bit. It took a
long time, but the fundamental difference is that eventual convergence was
always an objective and ongoing consideration. For example, later generations
of hardware such as Sup32-PISA and VS-720C dropped CatOS altogether (I seem to
recall hearing that dropping it with the original Sup720 was considered).

This allowed the underlying OS migration to be embarked upon independent of
capex cycles, such that for a many years, you never had to buy a device (ie.
chassis, line cards, etc) that would only be usable on for "the old OS that
we're not prepared to move off of yet". 

Though there's always bumps, but the GSR (IOS->XR) and 6500 (CatOS->IOS) were
well-executed, customer focused migrations that allowed each to move forward
without alienating an existing install base and complicating future purchasing
decisions.



From sethm at rollernet.us  Thu Sep 17 16:08:11 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 17 Sep 2009 13:08:11 -0700
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <1909324405.1463201253215909975.JavaMail.root@zmail.newpaltz.edu>
References: <1909324405.1463201253215909975.JavaMail.root@zmail.newpaltz.edu>
Message-ID: <4AB2972B.1010301@rollernet.us>

Bruce A. Locke wrote:
> ----- "Rodney Dunn" <rodunn at cisco.com> wrote:
> 
> | Please check the email thread a week or so back where I gave the
> | direct contacts for feedback.
> | 
> | They are open and want to hear helpful constructive feedback.
> 
> 
> I've sent them complaints before and filled out their surveys.  And this comes along.  Is it bombing for anyone else on Mac OS X?

I get stupid errors on my Mac like "already in your cart" and the cart
count stays zero.


> Excuse me while I try to relay my constructive criticism through our reseller.
> 

I think the only way Cisco will ever get the message is to stop
purchasing their products. I'm not holding my breath.

~Seth

From jay at west.net  Thu Sep 17 16:41:50 2009
From: jay at west.net (Jay Hennigan)
Date: Thu, 17 Sep 2009 13:41:50 -0700
Subject: [c-nsp] "Enhanced" download procedure - Cisco contact info
In-Reply-To: <4AB2972B.1010301@rollernet.us>
References: <1909324405.1463201253215909975.JavaMail.root@zmail.newpaltz.edu>
	<4AB2972B.1010301@rollernet.us>
Message-ID: <4AB29F0E.8080802@west.net>

I have opened a dialog and have gotten what seem to be reasonable 
responses from this person, who seems interested in our feedback.

Oscar Bauer - bauer at cisco.com

However, I just about had a "Joe Wilson moment" when he sent me the 
following:

"While we have seen some customers have challenges with the new
Java requirements, once we have been able to assist them getting their
configurations setup correctly most of them are happy with the new
changes."

Please send him a polite note.  There's always hope.

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

From sethm at rollernet.us  Thu Sep 17 16:47:10 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 17 Sep 2009 13:47:10 -0700
Subject: [c-nsp] "Enhanced" download procedure - Cisco contact info
In-Reply-To: <4AB29F0E.8080802@west.net>
References: <1909324405.1463201253215909975.JavaMail.root@zmail.newpaltz.edu>	<4AB2972B.1010301@rollernet.us>
	<4AB29F0E.8080802@west.net>
Message-ID: <4AB2A04E.2030007@rollernet.us>

Jay Hennigan wrote:
> I have opened a dialog and have gotten what seem to be reasonable
> responses from this person, who seems interested in our feedback.
> 
> Oscar Bauer - bauer at cisco.com
> 
> However, I just about had a "Joe Wilson moment" when he sent me the
> following:
> 
> "While we have seen some customers have challenges with the new
> Java requirements, once we have been able to assist them getting their
> configurations setup correctly most of them are happy with the new
> changes."
> 
> Please send him a polite note.  There's always hope.
> 

I would love to see how they react to a CLI-only environment.

~Seth

From ras at e-gerbil.net  Thu Sep 17 17:05:05 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Thu, 17 Sep 2009 16:05:05 -0500
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <20090917063822.GA27728@bts.sk>
References: <20090917063822.GA27728@bts.sk>
Message-ID: <20090917210505.GL51443@gerbil.cluepon.net>

On Thu, Sep 17, 2009 at 08:38:22AM +0200, Marian ??urkovi?? wrote:
> And, during the download it kept displaying that my download speed is
> 56 kb/s while the real speed was orders of magnitude higher.

When I noticed my download speed rapidly flickering back and forth 
between 10kb/s and 1000kb/s I figured they just reused the interface 
counter code from IOS. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From jared at puck.nether.net  Thu Sep 17 17:06:01 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 17 Sep 2009 17:06:01 -0400
Subject: [c-nsp] "Enhanced" download procedure - Cisco contact info
In-Reply-To: <4AB2A04E.2030007@rollernet.us>
References: <1909324405.1463201253215909975.JavaMail.root@zmail.newpaltz.edu>	<4AB2972B.1010301@rollernet.us>
	<4AB29F0E.8080802@west.net> <4AB2A04E.2030007@rollernet.us>
Message-ID: <BE3D6362-ED0F-4B02-BACF-9BD5F7C27053@puck.nether.net>


On Sep 17, 2009, at 4:47 PM, Seth Mattinen wrote:

> Jay Hennigan wrote:
>> I have opened a dialog and have gotten what seem to be reasonable
>> responses from this person, who seems interested in our feedback.
>>
>> Oscar Bauer - bauer at cisco.com
>>
>> However, I just about had a "Joe Wilson moment" when he sent me the
>> following:
>>
>> "While we have seen some customers have challenges with the new
>> Java requirements, once we have been able to assist them getting  
>> their
>> configurations setup correctly most of them are happy with the new
>> changes."
>>
>> Please send him a polite note.  There's always hope.
>>
>
> I would love to see how they react to a CLI-only environment.

Or one where javascript is seen as a security risk.

I will be in SJ next week, I've sent varying degrees of polite and  
frustrated notes to several parties.  I am hoping to engage in a  
dialogue in-person next week regarding this issue to solve the support  
challenge this creates for us.

	- Jared (Opposing the inhuman network)

From ryan at deadfrog.net  Thu Sep 17 17:11:28 2009
From: ryan at deadfrog.net (Ryan Wilkins)
Date: Thu, 17 Sep 2009 16:11:28 -0500
Subject: [c-nsp] "Enhanced" download procedure - Cisco contact info
In-Reply-To: <4AB29F0E.8080802@west.net>
References: <1909324405.1463201253215909975.JavaMail.root@zmail.newpaltz.edu>
	<4AB2972B.1010301@rollernet.us> <4AB29F0E.8080802@west.net>
Message-ID: <BEA3D448-FFDE-463F-AC7D-0037FBB5A751@deadfrog.net>


On Sep 17, 2009, at 3:41 PM, Jay Hennigan wrote:

> I have opened a dialog and have gotten what seem to be reasonable  
> responses from this person, who seems interested in our feedback.
>
> Oscar Bauer - bauer at cisco.com
>
> However, I just about had a "Joe Wilson moment" when he sent me the  
> following:
>
> "While we have seen some customers have challenges with the new
> Java requirements, once we have been able to assist them getting their
> configurations setup correctly most of them are happy with the new
> changes."
>
> Please send him a polite note.  There's always hope.
>
> --
> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
> Impulse Internet Service  -  http://www.impulse.net/
> Your local telephone and internet company - 805 884-6323 - WB6RDV


For what it's worth, I also sent a note to Oscar Bauer a couple days  
ago and received a very similar reply back from him.  Very cordial but  
not exactly what I was hoping to receive back.  It was almost like I  
was typing to the wind or something.

Regards,
Ryan Wilkins


From Stig.Johansen at atea.no  Thu Sep 17 16:56:14 2009
From: Stig.Johansen at atea.no (Stig Johansen)
Date: Thu, 17 Sep 2009 22:56:14 +0200
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AAFE01C.3080602@cisco.com>
References: <4AAFD139.4050402@west.net>	<4AAFD6B9.4050903@forthnet.gr>
	<4AAFD842.6030801@west.net>	<4AAFDB58.4040204@rollernet.us>
	<4AAFE01C.3080602@cisco.com>
Message-ID: <5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>

Rodney Dunn wrote:
>Please check the email thread a week or so back where I gave the direct contacts for feedback.
>They are open and want to hear helpful constructive feedback.
>Rodney

I'm really not in the mood for banging my head against the wall, so I'm asking for help from all on this list. This is a part of the reply Mr. Bauer gave me when I expressed my concerns with the inability to get a direct download-URL (to use with wget etc. from within the customer network through a SSH-session, which *was* a relatively common method I do believe):

Oscar Bauer wrote:
>Unfortunately we cannot enabled Wget, cURL, Fetching URLs, 
>crawling or scripting as these may have been possible to use 
>in the past but were never supported when download software 
>from Cisco.com. However there are several remote access clients 
>or capabilities built into each operating system that support 
>remote desktop access. Here are the steps to configure XP on 
>a windows box for remote access.
>http://www.microsoft.com/windowsXp/using/mobility/getstarted/Remoteintro.mspx 
>that would allow you to run a browser at that location to download 
>the files. If this is not a windows box there are a lot of 
>freeware options to choose from:
>http://en.wikipedia.org/wiki/Comparison_of_remote_desktop_software


/Stig

From peter at rathlev.dk  Thu Sep 17 17:33:43 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Thu, 17 Sep 2009 23:33:43 +0200
Subject: [c-nsp] "Enhanced" download procedure - Cisco contact info
In-Reply-To: <4AB29F0E.8080802@west.net>
References: <1909324405.1463201253215909975.JavaMail.root@zmail.newpaltz.edu>
	<4AB2972B.1010301@rollernet.us>  <4AB29F0E.8080802@west.net>
Message-ID: <1253223223.2695.3.camel@abehat.net.rm.dk>

On Thu, 2009-09-17 at 13:41 -0700, Jay Hennigan wrote:
> However, I just about had a "Joe Wilson moment" when he sent me the 
> following:
> 
> "While we have seen some customers have challenges with the new
> Java requirements, once we have been able to assist them getting their
> configurations setup correctly most of them are happy with the new
> changes."

Though I don't like swearing I simply has to utter: "WTF?!?" My setup is
perfectly correct as it is. I find the comment extremely arrogant.

-- 
Peter



From blocke at newpaltz.edu  Thu Sep 17 17:40:22 2009
From: blocke at newpaltz.edu (blocke at newpaltz.edu)
Date: Thu, 17 Sep 2009 17:40:22 -0400 (EDT)
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <339778724.1493401253223578898.JavaMail.root@zmail.newpaltz.edu>
Message-ID: <98424577.1493471253223622619.JavaMail.root@zmail.newpaltz.edu>


----- "Stig Johansen" <Stig.Johansen at atea.no> wrote:

| Oscar Bauer wrote:
| >Unfortunately we cannot enabled Wget, cURL, Fetching URLs, 
| >crawling or scripting as these may have been possible to use 
| >in the past but were never supported when download software 
| >from Cisco.com. However there are several remote access clients 
| >or capabilities built into each operating system that support 
| >remote desktop access. Here are the steps to configure XP on 
| >a windows box for remote access.
| >http://www.microsoft.com/windowsXp/using/mobility/getstarted/Remoteintro.mspx

Words fail.  Does Cisco not get this web thing?


-- 
Bruce A. Locke
blocke at newpaltz.edu
HAB 50 - (845) 257-3809

Network Administrator
Computer Services
State University of New York at New Paltz 


From sethm at rollernet.us  Thu Sep 17 17:46:21 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 17 Sep 2009 14:46:21 -0700
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>
References: <4AAFD139.4050402@west.net>	<4AAFD6B9.4050903@forthnet.gr>	<4AAFD842.6030801@west.net>	<4AAFDB58.4040204@rollernet.us>	<4AAFE01C.3080602@cisco.com>
	<5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>
Message-ID: <4AB2AE2D.1090508@rollernet.us>

Stig Johansen wrote:
> Rodney Dunn wrote:
>> Please check the email thread a week or so back where I gave the direct contacts for feedback.
>> They are open and want to hear helpful constructive feedback.
>> Rodney
> 
> I'm really not in the mood for banging my head against the wall, so I'm asking for help from all on this list. This is a part of the reply Mr. Bauer gave me when I expressed my concerns with the inability to get a direct download-URL (to use with wget etc. from within the customer network through a SSH-session, which *was* a relatively common method I do believe):
> 
> Oscar Bauer wrote:
>> Unfortunately we cannot enabled Wget, cURL, Fetching URLs, 
>> crawling or scripting as these may have been possible to use 
>> in the past but were never supported when download software 
>>from Cisco.com. However there are several remote access clients 
>> or capabilities built into each operating system that support 
>> remote desktop access. Here are the steps to configure XP on 
>> a windows box for remote access.
>> http://www.microsoft.com/windowsXp/using/mobility/getstarted/Remoteintro.mspx 
>> that would allow you to run a browser at that location to download 
>> the files. If this is not a windows box there are a lot of 
>> freeware options to choose from:
>> http://en.wikipedia.org/wiki/Comparison_of_remote_desktop_software
> 
> 


So, no GUI+java, no software center. Period.

~Seth

From jared at puck.nether.net  Thu Sep 17 17:50:28 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 17 Sep 2009 17:50:28 -0400
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AB2AE2D.1090508@rollernet.us>
References: <4AAFD139.4050402@west.net>	<4AAFD6B9.4050903@forthnet.gr>	<4AAFD842.6030801@west.net>	<4AAFDB58.4040204@rollernet.us>	<4AAFE01C.3080602@cisco.com>
	<5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>
	<4AB2AE2D.1090508@rollernet.us>
Message-ID: <2FF31569-E059-4426-99F6-3307B71ED2A0@puck.nether.net>


On Sep 17, 2009, at 5:46 PM, Seth Mattinen wrote:

>
> So, no GUI+java, no software center. Period.
>
> ~Seth

Actually, No javascript no software center.

	- Jared

From awain567 at yahoo.com  Thu Sep 17 17:58:51 2009
From: awain567 at yahoo.com (Alex Wa)
Date: Thu, 17 Sep 2009 14:58:51 -0700 (PDT)
Subject: [c-nsp] Limiting Telnet and SSH on a nexus 7018
Message-ID: <767502.1851.qm@web58001.mail.re3.yahoo.com>

Hi Guys,
?
I'm pretty new to NX-OS and so far I haven't been able to find any way to apply an ACL to the VTY, as with IOSs. What is the way to secure Telnet and?SSH access in this platform??Info is very scarse out there on this topic. I found a way by policing CoPP, matching an access-list and droping, but?I don't know if there is another, easier way to do it. 
?
Thanks,
Alejandro Wainshtok


      

From gsgranados at comcast.net  Thu Sep 17 19:20:31 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Thu, 17 Sep 2009 16:20:31 -0700
Subject: [c-nsp] "Enhanced" download procedure
References: <4AAFD139.4050402@west.net>	<4AAFD6B9.4050903@forthnet.gr><4AAFD842.6030801@west.net>	<4AAFDB58.4040204@rollernet.us><4AAFE01C.3080602@cisco.com>
	<5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>
Message-ID: <022601ca37ed$7901fa30$2208120a@am.thmulti.com>

Makes you long for the good ol days when a simple ftp ftp.cisco.com worked 
and only required your cco user / pass.

----- Original Message ----- 
From: "Stig Johansen" <Stig.Johansen at atea.no>
To: "Cisco Mailing list" <cisco-nsp at puck.nether.net>
Sent: Thursday, September 17, 2009 1:56 PM
Subject: Re: [c-nsp] "Enhanced" download procedure


> Rodney Dunn wrote:
>>Please check the email thread a week or so back where I gave the direct 
>>contacts for feedback.
>>They are open and want to hear helpful constructive feedback.
>>Rodney
>
> I'm really not in the mood for banging my head against the wall, so I'm 
> asking for help from all on this list. This is a part of the reply Mr. 
> Bauer gave me when I expressed my concerns with the inability to get a 
> direct download-URL (to use with wget etc. from within the customer 
> network through a SSH-session, which *was* a relatively common method I do 
> believe):
>
> Oscar Bauer wrote:
>>Unfortunately we cannot enabled Wget, cURL, Fetching URLs,
>>crawling or scripting as these may have been possible to use
>>in the past but were never supported when download software
>>from Cisco.com. However there are several remote access clients
>>or capabilities built into each operating system that support
>>remote desktop access. Here are the steps to configure XP on
>>a windows box for remote access.
>>http://www.microsoft.com/windowsXp/using/mobility/getstarted/Remoteintro.mspx
>>that would allow you to run a browser at that location to download
>>the files. If this is not a windows box there are a lot of
>>freeware options to choose from:
>>http://en.wikipedia.org/wiki/Comparison_of_remote_desktop_software
>
>
> /Stig
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From kloch at kl.net  Thu Sep 17 18:58:19 2009
From: kloch at kl.net (Kevin Loch)
Date: Thu, 17 Sep 2009 18:58:19 -0400
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AAFD139.4050402@west.net>
References: <4AAFD139.4050402@west.net>
Message-ID: <4AB2BF0B.8060300@kl.net>

Jay Hennigan wrote:
> What the #$^&$@# is going on with Cisco's download site?  It completely 
> hangs Firefox with some shopping cart java thing.  And this is downright 
> scary:  http://www.west.net/~jay/images/cisco-wants-root.png
> 
> Enhanced downloads, brought to you by the same people who brought us 
> enhanced interrogation?

Actually this is like feature terrorism with lots of collateral damage.

- Kevin

From naveen at lastninja.net  Thu Sep 17 20:23:13 2009
From: naveen at lastninja.net (Naveen Nathan)
Date: Thu, 17 Sep 2009 17:23:13 -0700
Subject: [c-nsp] Assistance configuring a router to trigger remote blackhole
Message-ID: <20090918002313.GB18289@armakuni.lastninja.net>

Hi,

I am new to the list, so please go easy on me.

I'm in need of assistance configuring remote trigger blackhole in
IOS. This feature is supported by our transit provider. I'm unsure
if it's working or not, but since the nulled routes don't appear to
be advertised to the transit peer, I'm assuming not.

I've attached a portion of the cisco-config (substituting sensitive info,
but it should be easy enough to follow).

Would someone mind suggesting if I'm missing anything of particular
importance. It would be much appreciated.
 
Thanks.

-- 
Naveen Nathan

To understand the human mind, understand self-deception. - Anon
-------------- next part --------------
router bgp [ROUTER_AS]
 no synchronization
 bgp router-id [ROUTER_IP]
 bgp log-neighbor-changes
 bgp maxas-limit 75
 network [BLOCK_A] mask 255.255.248.0 route-map AS[ROUTER_AS]-internal
 network [BLOCK_B] mask 255.255.252.0 route-map AS[ROUTER_AS]-internal
 network [BLOCK_C] mask 255.255.252.0 route-map AS[ROUTER_AS]-internal
 redistribute static route-map STATIC-TO-BGP
 neighbor AS[UPSTREAM_AS] peer-group
 neighbor AS[UPSTREAM_AS] remote-as [UPSTREAM_AS]
 neighbor AS[UPSTREAM_AS] password 7 !!!
 neighbor AS[UPSTREAM_AS] version 4
 neighbor AS[UPSTREAM_AS] send-community both
 neighbor AS[UPSTREAM_AS] remove-private-as
 neighbor AS[UPSTREAM_AS] soft-reconfiguration inbound
 neighbor AS[UPSTREAM_AS] prefix-list NULL in
 neighbor AS[UPSTREAM_AS] route-map OUTBOUND out
 neighbor [UPSTREAM_IP] peer-group AS[UPSTREAM_AS]
 maximum-paths 2
 no auto-summary
!
ip classless
ip route 0.0.0.0 0.0.0.0 [UPSTREAM_IP] name "Default Route"
ip route [BLOCK_A] 255.255.248.0 Null0 name "Component Null"
ip route [BLOCK_B] 255.255.252.0 Null0 name "Component Null"
ip route [BLOCK_C] 255.255.252.0 Null0 name "Component Null"
ip route [IP_IN_BLOCK_A] 255.255.255.255 Null0 tag 666
ip route [OUTSIDE_INTERNET_IP] 255.255.255.255 Null0 tag 666
!
ip bgp-community new-format
!
ip prefix-list NULL seq 5 deny 0.0.0.0/0 le 32
!
ip prefix-list OUTBOUND seq 5 permit [BLOCK_B]/22
ip prefix-list OUTBOUND seq 10 permit [BLOCK_C]/22
ip prefix-list OUTBOUND seq 15 permit [BLOCK_A]/21
!
route-map AS[ROUTER_AS]-internal permit 100
 set local-preference 150
 set weight 0
 set ip next-hop [ROUTER_IP]
!
route-map OUTBOUND permit 100
 description Deny Null Routes
 match community [UPSTREAM_AS]:666
!
route-map OUTBOUND permit 110
 description Allow internal routes
 match ip address prefix-list OUTBOUND
!
route-map STATIC-TO-BGP permit 50
 description Upstream Blackhole
 match tag 666
 set community [UPSTREAM_AS]:666
!

--- SNIP ---

lax3-core3#show ip bgp neighbors [UPSTREAM_IP] advertised-routes
BGP table version is 8, local router ID is [ROUTER_IP]
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> [BLOCK_A]/21  [ROUTER_IP]            0    150      0 i
*> [BLOCK_B]/22  [ROUTER_IP]            0    150      0 i
*> [BLOCK_C]/22  [ROUTER_IP]            0    150      0 i

Total number of prefixes 3

--- SNIP ---



lax3-core3#show ip route [IP_IN_BLOCK_A]
Routing entry for [IP_IN_BLOCK_A]/32
  Known via "static", distance 1, metric 0 (connected)
  Tag 666
  Redistributing via bgp [ROUTER_AS]
  Advertised by bgp [ROUTER_AS] route-map STATIC-TO-BGP
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1
      Route tag 666

lax3-core3#show ip route [OUTSIDE_INTERNET_IP]
Routing entry for [OUTSIDE_INTERNET_IP]/32
  Known via "static", distance 1, metric 0 (connected)
  Tag 666
  Redistributing via bgp [ROUTER_AS]
  Advertised by bgp [ROUTER_AS] route-map STATIC-TO-BGP
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1
      Route tag 666


From dcp at dcptech.com  Thu Sep 17 21:08:36 2009
From: dcp at dcptech.com (David Prall)
Date: Thu, 17 Sep 2009 21:08:36 -0400
Subject: [c-nsp] Assistance configuring a router to trigger remote
	blackhole
In-Reply-To: <20090918002313.GB18289@armakuni.lastninja.net>
References: <20090918002313.GB18289@armakuni.lastninja.net>
Message-ID: <005801ca37fc$9e5494f0$dafdbed0$@com>

I would have a look here:
http://www.team-cymru.org/Services/Bogons/routeserver.html

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/pro
d_white_paper0900aecd80313fac.pdf

They have a sample configuration. You will need uRPF configured on your
interfaces as well to do the actual dropping of traffic with these source
addresses. The remote routers will need to modify the next-hop on receiving
a route with the community x:666, although it appears you are only concerned
with the static routes.

David

--
http://dcp.dcptech.com
 

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Naveen Nathan
> Sent: Thursday, September 17, 2009 8:23 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Assistance configuring a router to trigger remote
> blackhole
> 
> Hi,
> 
> I am new to the list, so please go easy on me.
> 
> I'm in need of assistance configuring remote trigger blackhole in
> IOS. This feature is supported by our transit provider. I'm unsure
> if it's working or not, but since the nulled routes don't appear to
> be advertised to the transit peer, I'm assuming not.
> 
> I've attached a portion of the cisco-config (substituting sensitive
> info,
> but it should be easy enough to follow).
> 
> Would someone mind suggesting if I'm missing anything of particular
> importance. It would be much appreciated.
> 
> Thanks.
> 
> --
> Naveen Nathan
> 
> To understand the human mind, understand self-deception. - Anon


From chip.gwyn at gmail.com  Thu Sep 17 21:19:27 2009
From: chip.gwyn at gmail.com (chip)
Date: Thu, 17 Sep 2009 21:19:27 -0400
Subject: [c-nsp] Assistance configuring a router to trigger remote
	blackhole
In-Reply-To: <20090918002313.GB18289@armakuni.lastninja.net>
References: <20090918002313.GB18289@armakuni.lastninja.net>
Message-ID: <64a8ad980909171819m794d367cj5e0a8e840afc1bea@mail.gmail.com>

On Thu, Sep 17, 2009 at 8:23 PM, Naveen Nathan <naveen at lastninja.net> wrote:

> Hi,
>
> I am new to the list, so please go easy on me.
>
> I'm in need of assistance configuring remote trigger blackhole in
> IOS. This feature is supported by our transit provider. I'm unsure
> if it's working or not, but since the nulled routes don't appear to
> be advertised to the transit peer, I'm assuming not.
>
> I've attached a portion of the cisco-config (substituting sensitive info,
> but it should be easy enough to follow).
>
> Would someone mind suggesting if I'm missing anything of particular
> importance. It would be much appreciated.
>
> Thanks.
>
> --
> Naveen Nathan
>
> To understand the human mind, understand self-deception. - Anon
>

Try putting the community onto the routes in your OUTBOUND route-map, ie.

route-map OUTBOUND permit 100
 description Deny Null Routes
 match tag 666
 set community [UPSTREAM_AS]:666

Otherwise the community is only being set within your AS


--chip

-- 
Just my $.02, your mileage may vary,  batteries not included, etc....

From kgraham at industrial-marshmallow.com  Thu Sep 17 21:21:41 2009
From: kgraham at industrial-marshmallow.com (Kevin Graham)
Date: Thu, 17 Sep 2009 18:21:41 -0700 (PDT)
Subject: [c-nsp] Assistance configuring a router to trigger remote
	blackhole
In-Reply-To: <20090918002313.GB18289@armakuni.lastninja.net>
References: <20090918002313.GB18289@armakuni.lastninja.net>
Message-ID: <748810.5696.qm@web1208.biz.mail.gq1.yahoo.com>

> I'm unsure if it's working or not, but since the nulled routes don't

> appear to be advertised to the transit peer, I'm assuming not.

Does a 'sh ip route' for the /32 indicate that its being redistributed?
If you do a 'sh ip bgp nei <nei> adver' does it show it being advertised?


From andy.saykao at staff.netspace.net.au  Thu Sep 17 22:07:29 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Fri, 18 Sep 2009 12:07:29 +1000
Subject: [c-nsp] AnyConnect VPN client, IOS, and Vista
References: <mailman.1812.1253037091.2225.cisco-nsp@puck.nether.net>
Message-ID: <56F211C5E3F24F47B103EA1B253822BE044AAC2F@vic-cr-ex1.staff.netspace.net.au>

Jay,

I've been doing some testing with WebVPN and AnyConnect client and have
had no problems with Vista honouring the certificate. I'm using a 7301
as the SSL/WebVPN Gateway running IOS 12.4(24)T1.

My config resembles your config somewhat.
Below I've shown the relevant parts of my config.

crypto pki trustpoint TP-self-signed-74999113
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-74999113
 revocation-check none
 rsakeypair TP-self-signed-74999113
!
!
crypto pki certificate chain TP-self-signed-74999113
 certificate self-signed 01
!
webvpn gateway WEBVPN
 ip address A.B.C.D port 443
 http-redirect port 80
 ssl trustpoint TP-self-signed-74999113
 inservice
 !
webvpn install svc disk0:/webvpn/anyconnect-win-2.3.2016-k9.pkg sequence
1
 !
webvpn install svc
disk0:/webvpn/anyconnect-macosx-powerpc-2.3.2016-k9.pkg sequence 2
 !
webvpn install svc disk0:/webvpn/anyconnect-macosx-i386-2.3.2016-k9.pkg
sequence 3
 !
webvpn install svc disk0:/webvpn/anyconnect-linux-2.3.2016-k9.pkg
sequence 4
 !
webvpn context TUNNEL
 title "Tunnel Mode"
 ssl authenticate verify all
 !
 !
 policy group TUNNEL-GROUP
   functions svc-enabled
   svc address-pool "TUNNEL-POOL"
   svc keep-client-installed
   svc dpd-interval gateway 30
   svc homepage "http://192.168.2.2"
   svc rekey method new-tunnel
   svc split include 192.168.2.0 255.255.255.0
 vrf-name NSTEST
 default-group-policy TUNNEL-GROUP
 aaa authentication list NSTEST
 gateway WEBVPN domain tunnel
 inservice

I did have problems with the self signed certificate at one time when I
was unable to open the WebVPN portal because the certificate wasn't
valid. This was showing up in the router logs with a line saying
something along the lines of "key is inactive". To fix this, I
re-generated the certficate by removing it from the webvpn gateway
section with a "no ssl trustpoint TP-self-signed-74999113" and as I did
that it automatically re-gerneated a new certficiate. Been working ok
since.

Cheers.

Andy

This email and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed. 
Please notify the sender immediately by email if you have received this 
email by mistake and delete this email from your system. 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 organisation. 
Finally, the recipient should check this email and any attachments for 
the presence of viruses. The organisation accepts no liability for any 
damage caused by any virus transmitted by this email.


From davidwarner1975 at yahoo.com.au  Fri Sep 18 00:45:03 2009
From: davidwarner1975 at yahoo.com.au (David Warner)
Date: Thu, 17 Sep 2009 21:45:03 -0700 (PDT)
Subject: [c-nsp] HSRP/multicast help
Message-ID: <308997.98051.qm@web111604.mail.gq1.yahoo.com>

Hi, 

We have a requirement to provide gateway redundancy for a multicast enabled server(s) . Weve had a few issues with getting this working in a deterministic fashion.

Does anyone have a working config or tips on getting multicast working in a HSRP set up?

Many thanks. David.



      __________________________________________________________________________________
Get more done like never before with Yahoo!7 Mail.
Learn more: http://au.overview.mail.yahoo.com/

From naveen at lastninja.net  Fri Sep 18 01:37:04 2009
From: naveen at lastninja.net (Naveen Nathan)
Date: Thu, 17 Sep 2009 22:37:04 -0700
Subject: [c-nsp] Assistance configuring a router to trigger
	remote	blackhole
In-Reply-To: <748810.5696.qm@web1208.biz.mail.gq1.yahoo.com>
References: <20090918002313.GB18289@armakuni.lastninja.net>
	<748810.5696.qm@web1208.biz.mail.gq1.yahoo.com>
Message-ID: <20090918053703.GD18289@armakuni.lastninja.net>

> Does a 'sh ip route' for the /32 indicate that its being redistributed?
> If you do a 'sh ip bgp nei <nei> adver' does it show it being advertised?

Below I pasted excerpts from the router. The route appears to be
redistributed by the correct route-map. The STATIC-TO-BGP map proceeds
to set the community string, while the OUTBOUND route-map matches on the
same community string to advertise over BGP along with the networks. But
as displayed with the 'sh ip nei <peer> advertised-routes' it's not
displaying the host routes.

I'm wondering if I missed something in the OUTBOUND route-map to
not match host-routes. It appears you cannot match tags for
route-maps used for advertising to peers, so I match on the community
string instead.

I also have send-communities configured for the upstream peer, so I
believe the community string should be retained for the route when the
OUTBOUND route-map is evaluated.

--- snip ---

# sh ip route [IP_IN_BLOCK_A]
Routing entry for [IP_IN_BLOCK_A]/32
  Known via "static", distance 1, metric 0 (connected)
  Tag 666
  Redistributing via bgp [ROUTER_AS]
  Advertised by bgp [ROUTER_AS] route-map STATIC-TO-BGP
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1
      Route tag 666

# show ip bgp neighbors [UPSTREAM_IP] advertised-routes
BGP table version is 8, local router ID is [ROUTER_IP]
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> [BLOCK_A]/21  [ROUTER_IP]            0    150      0 i
*> [BLOCK_B]/22  [ROUTER_IP]            0    150      0 i
*> [BLOCK_C]/22  [ROUTER_IP]            0    150      0 i

Total number of prefixes 3

From hank at efes.iucc.ac.il  Fri Sep 18 01:41:00 2009
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Fri, 18 Sep 2009 08:41:00 +0300 (IDT)
Subject: [c-nsp] "Enhanced" download procedure - Cisco contact info
In-Reply-To: <4AB29F0E.8080802@west.net>
References: <1909324405.1463201253215909975.JavaMail.root@zmail.newpaltz.edu>
	<4AB2972B.1010301@rollernet.us> <4AB29F0E.8080802@west.net>
Message-ID: <Pine.LNX.4.64.0909180840480.19016@efes.iucc.ac.il>

On Thu, 17 Sep 2009, Jay Hennigan wrote:

Dream on.

-Hank

> I have opened a dialog and have gotten what seem to be reasonable responses 
> from this person, who seems interested in our feedback.
>
> Oscar Bauer - bauer at cisco.com
>
> However, I just about had a "Joe Wilson moment" when he sent me the 
> following:
>
> "While we have seen some customers have challenges with the new
> Java requirements, once we have been able to assist them getting their
> configurations setup correctly most of them are happy with the new
> changes."
>
> Please send him a polite note.  There's always hope.
>
> --
> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
> Impulse Internet Service  -  http://www.impulse.net/
> Your local telephone and internet company - 805 884-6323 - WB6RDV
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From hank at efes.iucc.ac.il  Fri Sep 18 02:00:44 2009
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Fri, 18 Sep 2009 09:00:44 +0300 (IDT)
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>
References: <4AAFD139.4050402@west.net> <4AAFD6B9.4050903@forthnet.gr>
	<4AAFD842.6030801@west.net> <4AAFDB58.4040204@rollernet.us>
	<4AAFE01C.3080602@cisco.com>
	<5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>
Message-ID: <Pine.LNX.4.64.0909180855560.19079@efes.iucc.ac.il>

On Thu, 17 Sep 2009, Stig Johansen wrote:

I've gone this road in the past a few times - feedback forms, Gold partner 
escalation, emailing Cisco managers, and other than burning my time - 
nothing good comes of it.  Cisco has shed any people that truly understand 
how things should work and what is left is more or less the bottom of the 
barrel (in the web interface area - not router and switch development).

So other than catharsis:
http://www.mail-archive.com/cisco-nsp at puck.nether.net/msg22723.html
your attempts to change Cisco are futile.

-Hank


> Rodney Dunn wrote:
>> Please check the email thread a week or so back where I gave the direct contacts for feedback.
>> They are open and want to hear helpful constructive feedback.
>> Rodney
>
> I'm really not in the mood for banging my head against the wall, so I'm asking for help from all on this list. This is a part of the reply Mr. Bauer gave me when I expressed my concerns with the inability to get a direct download-URL (to use with wget etc. from within the customer network through a SSH-session, which *was* a relatively common method I do believe):
>
> Oscar Bauer wrote:
>> Unfortunately we cannot enabled Wget, cURL, Fetching URLs,
>> crawling or scripting as these may have been possible to use
>> in the past but were never supported when download software
>> from Cisco.com. However there are several remote access clients
>> or capabilities built into each operating system that support
>> remote desktop access. Here are the steps to configure XP on
>> a windows box for remote access.
>> http://www.microsoft.com/windowsXp/using/mobility/getstarted/Remoteintro.mspx
>> that would allow you to run a browser at that location to download
>> the files. If this is not a windows box there are a lot of
>> freeware options to choose from:
>> http://en.wikipedia.org/wiki/Comparison_of_remote_desktop_software
>
>
> /Stig
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From md at bts.sk  Fri Sep 18 02:16:34 2009
From: md at bts.sk (=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=)
Date: Fri, 18 Sep 2009 08:16:34 +0200
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <2FF31569-E059-4426-99F6-3307B71ED2A0@puck.nether.net>
References: <4AAFD139.4050402@west.net>	<4AAFD6B9.4050903@forthnet.gr>	<4AAFD842.6030801@west.net>	<4AAFDB58.4040204@rollernet.us>	<4AAFE01C.3080602@cisco.com>
	<5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>
	<4AB2AE2D.1090508@rollernet.us>
	<2FF31569-E059-4426-99F6-3307B71ED2A0@puck.nether.net>
Message-ID: <20090918061609.M26973@bts.sk>

On Thu, 17 Sep 2009 17:50:28 -0400, Jared Mauch wrote
> On Sep 17, 2009, at 5:46 PM, Seth Mattinen wrote:
> 
> >
> > So, no GUI+java, no software center. Period.
> >
> > ~Seth
> 
> Actually, No javascript no software center.

Are you sure? The requirements list java, and when I disable it and leave
javascript enabled, it really doesn't work.

BTW, the responses from Cisco just make me wonder whether this java applet is
not actually there to do some "extra" work behind the scenes...

    M.

From alex at digriz.org.uk  Fri Sep 18 04:04:03 2009
From: alex at digriz.org.uk (Alexander Clouter)
Date: Fri, 18 Sep 2009 09:04:03 +0100
Subject: [c-nsp] HSRP/multicast help
References: <308997.98051.qm@web111604.mail.gq1.yahoo.com>
Message-ID: <jgrbo6-4rr.ln1@chipmunk.wormnet.eu>

Hi,

David Warner <davidwarner1975 at yahoo.com.au> wrote:
> 
> We have a requirement to provide gateway redundancy for a multicast 
> enabled server(s) . Weve had a few issues with getting this working in 
> a deterministic fashion.
> 
> Does anyone have a working config or tips on getting multicast working 
> in a HSRP set up?
> 
You probably are using 'standby x priority'?  We had the same issue 
years ago.

You *should* set up your VLAN's like so (example for a /24):

.0	network address
.1	HSRP gateway address
...	workstations
.253	HSRP *standy* router address
.254	HSRP *active* router address
.255	broadcast address

I personally remove the standby priorities from the VLAN configs as the 
'active' router will be the one with the higher IP address...which is 
*also* the rule for PIM.

What is probably happening is the PIM router for the subnet is your 
standby router and you are being hit with a lot of reverse path 
filtering issues[1].

If you really want to use standby priorities, make sure the higher 
number sits on the router with the higher IP address....however once you 
have done this you will wonder why

If you have not already, I would use this as an opportunity to move to 
using HSRPv2 or VRRP...and make sure you are using a shared secret to 
prevent someone spoofing that they are a HSRP gateway (plus enable 
IGMPv3).

An example for a /25 is below:
---- one of our 6509's ----
interface Vlan100
 description test
 ip address 1.2.3.126 255.255.255.224
 ip pim sparse-mode
 ip igmp version 3
 standby version 2
 standby 100 ip 1.2.3.1
 standby 100 preempt delay minimum 120
 standby 100 authentication md5 key-string <ahem>
----
---- the other of our 6509's ----
interface Vlan100
 description test
 ip address 1.2.3.125 255.255.255.224
 ip pim sparse-mode
 ip igmp version 3
 standby version 2
 standby 100 ip 1.2.3.1
 standby 100 preempt delay minimum 120
 standby 100 authentication md5 key-string <ahem>
----

If you are seeing high CPU usage on your routers, you might want to add:
----
mls rate-limit multicast ipv4 non-rpf 100 10
mls rate-limit multicast ipv4 partial 250 100
----

Cheers

[1] or it is because the IGMP joins never reach the PIM gateway as they 
	are going to the wrong router, I can never remember, it was 
	years ago when we fixed this

-- 
Alexander Clouter
.sigmonster says: Philosophy will clip an angel's wings.
                  		-- John Keats


From mat_cameron at msn.com  Fri Sep 18 04:11:56 2009
From: mat_cameron at msn.com (Mat Cameron)
Date: Fri, 18 Sep 2009 09:11:56 +0100
Subject: [c-nsp] Multicast VPN Caveats
Message-ID: <COL117-W503921200F8D86B9A7F4849BE00@phx.gbl>


Guys

I have a rather simple VPN setup that has a DLS connected to 1 RR and 2 PEs. When I was using non MDT SAFI capable IOS everything worked well. I then changed one PE and the RR to MDT SAFI capable and then i hit dramas. It seems that the non MDT SAFI supporting PE doesn't find a PIM neighbor, however the MDT SAFI supporting PE does find a PIM neighbor. I have looked at a white paper that mentions caveats CSCsf31082 and CSCek38025. so does anyone have any info on this cavaets?

Cheers

Mat
 		 	   		  
_________________________________________________________________
Get the best of MSN on your mobile
http://clk.atdmt.com/UKM/go/147991039/direct/01/

From gert at greenie.muc.de  Fri Sep 18 06:36:32 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 18 Sep 2009 12:36:32 +0200
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>
References: <4AAFD139.4050402@west.net> <4AAFD6B9.4050903@forthnet.gr>
	<4AAFD842.6030801@west.net> <4AAFDB58.4040204@rollernet.us>
	<4AAFE01C.3080602@cisco.com>
	<5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>
Message-ID: <20090918103632.GT1508@greenie.muc.de>

Hi,

On Thu, Sep 17, 2009 at 10:56:14PM +0200, Stig Johansen wrote:
> Oscar Bauer wrote:
> >Unfortunately we cannot enabled Wget, cURL, Fetching URLs, 
> >crawling or scripting as these may have been possible to use 
> >in the past but were never supported when download software 
> >from Cisco.com. However there are several remote access clients 
> >or capabilities built into each operating system that support 
> >remote desktop access. Here are the steps to configure XP on 

This is very obvious a person that never had to do remote network maintenance
before.  As in "I'm sitting in a a hotel, the link is congested and the
latency is high, but I *need* to get this update to that router box".

I'm all willing to work with Cisco if they listen, but *this* attitude
is not considered "listening" - it's "preaching their own belief how the
world should be".

*sigh*

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090918/15876723/attachment-0001.bin>

From eric at atlantech.net  Fri Sep 18 07:06:27 2009
From: eric at atlantech.net (Eric Van Tol)
Date: Fri, 18 Sep 2009 07:06:27 -0400
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <20090918103632.GT1508@greenie.muc.de>
References: <4AAFD139.4050402@west.net> <4AAFD6B9.4050903@forthnet.gr>
	<4AAFD842.6030801@west.net> <4AAFDB58.4040204@rollernet.us>
	<4AAFE01C.3080602@cisco.com>
	<5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>
	<20090918103632.GT1508@greenie.muc.de>
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863B3E882018@exchange.aoihq.local>

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Gert Doering
> Sent: Friday, September 18, 2009 6:37 AM
> To: Stig Johansen
> Cc: Cisco Mailing list
> Subject: Re: [c-nsp] "Enhanced" download procedure
> 
> Hi,
> 
> On Thu, Sep 17, 2009 at 10:56:14PM +0200, Stig Johansen wrote:
> > Oscar Bauer wrote:
> > >Unfortunately we cannot enabled Wget, cURL, Fetching URLs,
> > >crawling or scripting as these may have been possible to use
> > >in the past but were never supported when download software
> > >from Cisco.com. However there are several remote access clients
> > >or capabilities built into each operating system that support
> > >remote desktop access. Here are the steps to configure XP on
> 
> This is very obvious a person that never had to do remote network
> maintenance
> before.  As in "I'm sitting in a a hotel, the link is congested and the
> latency is high, but I *need* to get this update to that router box".
> 
> I'm all willing to work with Cisco if they listen, but *this* attitude
> is not considered "listening" - it's "preaching their own belief how the
> world should be".
> 
> *sigh*
> 
> gert

Clicking through multiple authentication windows to get where you need on Cisco's site:  12 seconds
Using Software Advisor to find the right IOS:  8 minutes
Downloading IOS to a remote machine, then transferring the image to your real T/FTP/SCP server:  15 minutes
Loading the image on your router just to find out that Software Advisor is junk and your specific WIC/NM/PA/WS version isn't recognized by said image, thereby forcing you to invent a way to strangle Cisco web tool designers through standard TCP/IP:  Priceless.

-evt

From Oliver.Dewdney at LBi.com  Fri Sep 18 07:21:26 2009
From: Oliver.Dewdney at LBi.com (Oliver Dewdney)
Date: Fri, 18 Sep 2009 12:21:26 +0100
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <20090918103632.GT1508@greenie.muc.de>
References: <4AAFD139.4050402@west.net> <4AAFD6B9.4050903@forthnet.gr>
	<4AAFD842.6030801@west.net> <4AAFDB58.4040204@rollernet.us>
	<4AAFE01C.3080602@cisco.com>
	<5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>
	<20090918103632.GT1508@greenie.muc.de>
Message-ID: <DD8F8D35B252094B813ADA95905F4AFD21216127B4@ukexhcm1.lbi.local>

We are all obviously missing all the wonderful features this new service provides!

>We have recently introduced the Download Cart in the Download Software area which has following features -
>
>1. You can download up to 25 files at a time.
>
>2. Download Manager allows you to monitor, pause/resume or cancel the software downloads
>
>3. You could see the image details in one screen for images which you have selected in the Download Cart, click on the >image row or on the expand icon (plus sign) in the cart for the image details.
>
>Please feel free to provide any additional feedback or concerns you have.


Except I can't think which one of those I wanted most.

Oli


>-----Original Message-----
>From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
>bounces at puck.nether.net] On Behalf Of Gert Doering
>Sent: 18 September 2009 11:37
>To: Stig Johansen
>Cc: Cisco Mailing list
>Subject: Re: [c-nsp] "Enhanced" download procedure
>
>Hi,
>
>On Thu, Sep 17, 2009 at 10:56:14PM +0200, Stig Johansen wrote:
>> Oscar Bauer wrote:
>> >Unfortunately we cannot enabled Wget, cURL, Fetching URLs, crawling
>> >or scripting as these may have been possible to use in the past but
>> >were never supported when download software from Cisco.com. However
>> >there are several remote access clients or capabilities built into
>> >each operating system that support remote desktop access. Here are
>> >the steps to configure XP on
>
>This is very obvious a person that never had to do remote network
>maintenance before.  As in "I'm sitting in a a hotel, the link is
>congested and the latency is high, but I *need* to get this update to
>that router box".
>
>I'm all willing to work with Cisco if they listen, but *this* attitude
>is not considered "listening" - it's "preaching their own belief how the
>world should be".
>
>*sigh*
>
>gert
>
>--
>USENET is *not* the non-clickable part of WWW!
>
>//www.muc.de/~gert/
>Gert Doering - Munich, Germany
>gert at greenie.muc.de
>fax: +49-89-35655025                        gert at net.informatik.tu-
>muenchen.de

LBi Ltd is registered in England and Wales, the registered number and address are 03080409, Truman Brewery, 146 Brick Lane, London, E1 6RU.  This email may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

From gert at greenie.muc.de  Fri Sep 18 07:40:57 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 18 Sep 2009 13:40:57 +0200
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <DD8F8D35B252094B813ADA95905F4AFD21216127B4@ukexhcm1.lbi.local>
References: <4AAFD139.4050402@west.net> <4AAFD6B9.4050903@forthnet.gr>
	<4AAFD842.6030801@west.net> <4AAFDB58.4040204@rollernet.us>
	<4AAFE01C.3080602@cisco.com>
	<5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>
	<20090918103632.GT1508@greenie.muc.de>
	<DD8F8D35B252094B813ADA95905F4AFD21216127B4@ukexhcm1.lbi.local>
Message-ID: <20090918114057.GU1508@greenie.muc.de>

Hi,

On Fri, Sep 18, 2009 at 12:21:26PM +0100, Oliver Dewdney wrote:
> >1. You can download up to 25 files at a time.

Now this is obviously a wonderful replacement for this old-fashioned
"mget *-is.vz*" thingie those poor geeks must use in the ancient times.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090918/6d224dc3/attachment.bin>

From eric at atlantech.net  Fri Sep 18 08:59:26 2009
From: eric at atlantech.net (Eric Van Tol)
Date: Fri, 18 Sep 2009 08:59:26 -0400
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <20090918114057.GU1508@greenie.muc.de>
References: <4AAFD139.4050402@west.net> <4AAFD6B9.4050903@forthnet.gr>
	<4AAFD842.6030801@west.net> <4AAFDB58.4040204@rollernet.us>
	<4AAFE01C.3080602@cisco.com>
	<5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>
	<20090918103632.GT1508@greenie.muc.de>
	<DD8F8D35B252094B813ADA95905F4AFD21216127B4@ukexhcm1.lbi.local>
	<20090918114057.GU1508@greenie.muc.de>
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863B3E88201C@exchange.aoihq.local>

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Gert Doering
> Sent: Friday, September 18, 2009 7:41 AM
> To: Oliver Dewdney
> Cc: Gert Doering; Cisco Mailing list
> Subject: Re: [c-nsp] "Enhanced" download procedure
> 
> Hi,
> 
> On Fri, Sep 18, 2009 at 12:21:26PM +0100, Oliver Dewdney wrote:
> > >1. You can download up to 25 files at a time.
> 
> Now this is obviously a wonderful replacement for this old-fashioned
> "mget *-is.vz*" thingie those poor geeks must use in the ancient times.
> 
> gert
> --

"Tired of downloading software that surprises you upon installation by covertly removes features that you used extensively in your previous version?  How about features Software Advisor says the IOS you're downloading supports features and hardware that meet your requirements, but actually does the complete opposite?  Well, Cisco has created a tool just for you - download up to 25 versions of IOS and we can guarantee with 85% accuracy that at least ONE of them will work."

My impression is that they take their feedback from customers that don't use the Cisco site all that often and are caught up in the mythical "Web 2.0" garbage that keeps infecting the internet.

-evt

From dwcarder at wisc.edu  Fri Sep 18 10:13:26 2009
From: dwcarder at wisc.edu (Dale W. Carder)
Date: Fri, 18 Sep 2009 09:13:26 -0500
Subject: [c-nsp] HSRP/multicast help
In-Reply-To: <jgrbo6-4rr.ln1@chipmunk.wormnet.eu>
References: <308997.98051.qm@web111604.mail.gq1.yahoo.com>
	<jgrbo6-4rr.ln1@chipmunk.wormnet.eu>
Message-ID: <89CC8A66-83E6-4C55-B545-14FFEAE706F4@wisc.edu>


On Sep 18, 2009, at 3:04 AM, Alexander Clouter wrote:
>
> I personally remove the standby priorities from the VLAN configs as  
> the
> 'active' router will be the one with the higher IP address...which is
> *also* the rule for PIM.
>
> What is probably happening is the PIM router for the subnet is your
> standby router and you are being hit with a lot of reverse path
> filtering issues[1].

Also, in addition to the higher ip address tiebreaker, you can
set the DR priority:

primary:
  ip pim dr-priority 4294967294

standby:
  ip pim dr-priority 2147483647  (or whatever)

This is very helpful if someone attaches a pim speaking device
and your ip addresses are at the bottom of the range rather than
the top.

Dale


From david.freedman at uk.clara.net  Fri Sep 18 10:45:57 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Fri, 18 Sep 2009 15:45:57 +0100
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AB2BF0B.8060300@kl.net>
References: <4AAFD139.4050402@west.net> <4AB2BF0B.8060300@kl.net>
Message-ID: <h906f5$b39$1@ger.gmane.org>

I don't seem to be able to make it work at all, I get

"There was a problem retrieving your cart information due to application
error. Please contact applications support."

Dave.


From steve at ibctech.ca  Fri Sep 18 12:36:36 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 18 Sep 2009 12:36:36 -0400
Subject: [c-nsp] Assistance configuring a router to trigger remote
	blackhole
In-Reply-To: <20090918002313.GB18289@armakuni.lastninja.net>
References: <20090918002313.GB18289@armakuni.lastninja.net>
Message-ID: <4AB3B714.7050207@ibctech.ca>

Naveen Nathan wrote:
> Hi,
> 
> I am new to the list, so please go easy on me.
> 
> I'm in need of assistance configuring remote trigger blackhole in
> IOS. This feature is supported by our transit provider. I'm unsure
> if it's working or not, but since the nulled routes don't appear to
> be advertised to the transit peer, I'm assuming not.
> 
> I've attached a portion of the cisco-config (substituting sensitive info,
> but it should be easy enough to follow).
> 
> Would someone mind suggesting if I'm missing anything of particular
> importance. It would be much appreciated.

If I understand you correctly, wouldn't one need an extra entry in the
OUTBOUND prefix-list that allows host routes to be advertised to the
transit?:

ip bgp-community new-format
!
ip prefix-list NULL seq 5 deny 0.0.0.0/0 le 32
!
ip prefix-list OUTBOUND seq 5 permit [BLOCK_B]/22
ip prefix-list OUTBOUND seq 10 permit [BLOCK_C]/22
ip prefix-list OUTBOUND seq 15 permit [BLOCK_A]/21

! just an example for illustration... it looks kind of dangerous
ip prefix-list OUTBOUND seq 20 permit 0.0.0.0/0 le 32

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090918/bd4a18be/attachment.bin>

From alex at digriz.org.uk  Fri Sep 18 12:57:08 2009
From: alex at digriz.org.uk (Alexander Clouter)
Date: Fri, 18 Sep 2009 17:57:08 +0100
Subject: [c-nsp] HSRP/multicast help
References: <308997.98051.qm@web111604.mail.gq1.yahoo.com>
	<jgrbo6-4rr.ln1@chipmunk.wormnet.eu>
	<89CC8A66-83E6-4C55-B545-14FFEAE706F4@wisc.edu>
Message-ID: <4oqco6-77u.ln1@chipmunk.wormnet.eu>

Hi,

Dale W. Carder <dwcarder at wisc.edu> wrote:
> 
> On Sep 18, 2009, at 3:04 AM, Alexander Clouter wrote:
>>
>> I personally remove the standby priorities from the VLAN configs as  
>> the
>> 'active' router will be the one with the higher IP address...which is
>> *also* the rule for PIM.
>>
>> What is probably happening is the PIM router for the subnet is your
>> standby router and you are being hit with a lot of reverse path
>> filtering issues[1].
> 
> Also, in addition to the higher ip address tiebreaker, you can
> set the DR priority:
> 
> primary:
>  ip pim dr-priority 4294967294
> 
> standby:
>  ip pim dr-priority 2147483647  (or whatever)
> 
> This is very helpful if someone attaches a pim speaking device
> and your ip addresses are at the bottom of the range rather than
> the top.
> 
I like it, any reason I cannot use 4294967293 on the standby?

Cheers

-- 
Alexander Clouter
.sigmonster says: No solicitors.


From SPfister at dps.k12.oh.us  Fri Sep 18 14:08:46 2009
From: SPfister at dps.k12.oh.us (Steven Pfister)
Date: Fri, 18 Sep 2009 14:08:46 -0400
Subject: [c-nsp] Need help troubleshooting CRC errors
In-Reply-To: <436848D1ED9646638E260E7AE456D593@int.convex.pt>
References: <4AB211D9.9E6F.00B8.0@dps.k12.oh.us>
	<436848D1ED9646638E260E7AE456D593@int.convex.pt>
Message-ID: <4AB39469.9E6F.00B8.0@dps.k12.oh.us>

Thanks for the link... I have a little more detail about the problem now:

'show atm pvc x/y' shows:

CrcErrors: 69402, SarTimeOuts: 2, OverSizedSDUs: 0, LengthViolation: 69294, CPIErrors: 0

Also, the router side shows, on 'show int':

  MTU 1500 bytes, sub MTU 1500, BW 155000 Kbit, DLY 80 usec,

router side, on 'show atm int atm':

Max. Datagram Size: 1558

8510 switch side, on 'show int':

  MTU 4470 bytes, sub MTU 4470, BW 155520 Kbit, DLY 0 usec,

Would this be a problem?

Steve Pfister
Technical Coordinator, 
The Office of Information Technology
Dayton Public Schools
115 S. Ludlow St. 
Dayton, OH 45402
 
Office (937) 542-3149
Cell (937) 673-6779
Direct Connect: 137*131747*8
Email spfister at dps.k12.oh.us


>>> "Antonio Soares" <amsoares at netcabo.pt> 9/17/2009 11:45 AM >>>
Try this document:

CRC Troubleshooting Guide for ATM Interfaces

http://www.cisco.com/en/US/tech/tk39/tk48/technologies_tech_note09186a00800c93ef.shtml 


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Steven Pfister
Sent: quinta-feira, 17 de Setembro de 2009 15:39
To: cisco-nsp at puck.nether.net 
Subject: [c-nsp] Need help troubleshooting CRC errors

Some of our older remote sites are connected via ATM. Two or three T1s come into an Cisco 8510, and from there a 155mbps OC3
connection over fiber to a 3640 router. Lately, I've been noticing that pretty much every one of them is showing what I think is a
rather high receive error count on the 3640 end of the OC3 connection, and it all seems to be CRC errors. Not much of any errors are
showing up on the 8510 end of the OC3 connection. For example, one site yesterday late afternoon showed 63, 763 receive errors for
the day. Several others were in the 20Ks. I'm not really certain what the cause might be, or where to start. Can anyone help?

Thanks!


Steve Pfister
Technical Coordinator,
The Office of Information Technology
Dayton Public Schools
115 S. Ludlow St. 
Dayton, OH 45402
 
Office (937) 542-3149
Cell (937) 673-6779
Direct Connect: 137*131747*8
Email spfister at dps.k12.oh.us 


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp 
archive at http://puck.nether.net/pipermail/cisco-nsp/ 




From drais at icantclick.org  Fri Sep 18 14:57:24 2009
From: drais at icantclick.org (david raistrick)
Date: Fri, 18 Sep 2009 14:57:24 -0400 (EDT)
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <98424577.1493471253223622619.JavaMail.root@zmail.newpaltz.edu>
References: <98424577.1493471253223622619.JavaMail.root@zmail.newpaltz.edu>
Message-ID: <alpine.BSF.2.00.0909181456280.34749@murf.icantclick.org>

On Thu, 17 Sep 2009, blocke at newpaltz.edu wrote:

> Words fail.  Does Cisco not get this web thing?

No, and they never have.  Anyone who's ever tried to -find- anything on 
their sites (internal facing or external facing) knows that. :)

Boggle.


--
david raistrick        http://www.netmeister.org/news/learn2quote.html
drais at icantclick.org             http://www.expita.com/nomime.html


From jared at puck.nether.net  Fri Sep 18 15:14:53 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 18 Sep 2009 15:14:53 -0400
Subject: [c-nsp] fake-workaround ... Re:  "Enhanced" download procedure
In-Reply-To: <alpine.BSF.2.00.0909181456280.34749@murf.icantclick.org>
References: <98424577.1493471253223622619.JavaMail.root@zmail.newpaltz.edu>
	<alpine.BSF.2.00.0909181456280.34749@murf.icantclick.org>
Message-ID: <D49C1A85-BB57-42E0-8301-472E1A83A91E@puck.nether.net>

So when you get to the following page where it says "If your download  
does not start "click here", you can "view source" with your web  
browser, and look for the following important components:

eg:

fileName":"s72033-advipservicesk9-mz.122-33.SXI2a.bin"
filePath":"/swc/esd/03/crypto/3DES/281569550/contract"
ftpServerName":"download-sj.cisco.com"

If you go ahead and combine these into:

http://download-sj.cisco.com/swc/esd/03/crypto/3DES/281569550/contract/s72033-advipservicesk9-mz.122-33.SXI2a.bin 
  you can use LYNX (if it has SSL support) still to do the siteminder  
cookie fu and fetch your image.

Why they won't just expose these links directly is foolish and a  
problem.

I do suggest we have a "download-day" where everyone opens a tac case  
at the same time to get the direct link to images.

- Jared


From kloch at kl.net  Fri Sep 18 15:21:09 2009
From: kloch at kl.net (Kevin Loch)
Date: Fri, 18 Sep 2009 15:21:09 -0400
Subject: [c-nsp] 12.2(18)SXD to 12.2(33)SRB|C|D
In-Reply-To: <9CBBDD05-9C33-4108-9D0F-85255604AEE3@lixfeld.ca>
References: <B32314DD-B600-40F0-A6EE-AD1D1A4736A5@lixfeld.ca>	<20090914203953.GE51443@gerbil.cluepon.net>	<200909151845.51812.mtinka@globaltransit.net>
	<9CBBDD05-9C33-4108-9D0F-85255604AEE3@lixfeld.ca>
Message-ID: <4AB3DDA5.7010100@kl.net>

Jason Lixfeld wrote:

> 3- There is one device on the network (an ASR1002 running 2.4.0) that is 
> unable to see the loopback address via OSPF from this 7600 we just 
> upgraded.  It's built an adjacency with the 7600, so it's not an MTU 
> thing, it just doesnt see the route for it's loopback interface. 

Make sure the ospf network mode on the interface (ip ospf network
broadcast/point-to-point etc) is set correctly and to match the
neighbor settings.

- Kevin



From cnsp at shreddedmail.com  Fri Sep 18 16:47:11 2009
From: cnsp at shreddedmail.com (Rick Ernst)
Date: Fri, 18 Sep 2009 13:47:11 -0700
Subject: [c-nsp] BGP and remote POPs with individual upstreams
Message-ID: <d066472f0909181347v1a7614b0p578b9d65bd1ae1bf@mail.gmail.com>

My Cisco bookshelf isn't helping me much with this...

We currently have a single POP with border/core/aggregation topology.
Upstreams each come in on their own border router and the core is used as a
route-reflector for border and aggregation. The internal network uses OSPF
as an IGP and each device is dual-connected for redundancy on independent
layer-2 networks.  OSPF load-shares with loopback IPs and IBGP uses the
loopback addresses for peering.

We are looking at turning up two additional POPs in the metro area, each
connected by redundant GigE loops to the original POP.  Each POP may have
zero or more direct upstream connections.  I'd like local traffic at each
POP to prefer both in and outbound traffic via the local upstream, but still
be able to failover to upstreams at other POPs if needed.

My initial thoughts are to BGP peer between POPs with a higher local-pref
for the local outbound traffic and to prepend between the POPs so inbound
traffic is more likely to take the shortest path inbound.


Is this too simplistic? Prone to trouble? What gotchas should I be looking
at, or other designs should I be considering?

Thanks!

From gert at greenie.muc.de  Fri Sep 18 17:04:30 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 18 Sep 2009 23:04:30 +0200
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <412409.56453.qm@web1206.biz.mail.gq1.yahoo.com>
References: <4AA8E79E.2030109@sara.nl> <20090910121617.GH1508@greenie.muc.de>
	<373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>
	<CD0195AB-DF6F-4B41-83BD-0E6F5F0BADF9@puck.nether.net>
	<20090914143623.GE1508@greenie.muc.de>
	<20090914163011.GC25690@lboro.ac.uk>
	<20090916080639.GX1508@greenie.muc.de>
	<0E0ADFB3-3D29-4857-B6B4-92E8698B026E@hughes.com.au>
	<alpine.WNT.2.00.0909171006020.3984@pckoug1.intranet.gr>
	<412409.56453.qm@web1206.biz.mail.gq1.yahoo.com>
Message-ID: <20090918210430.GY1508@greenie.muc.de>

Hi,

On Thu, Sep 17, 2009 at 12:46:44PM -0700, Kevin Graham wrote:
> Though there's always bumps, but the GSR (IOS->XR) and 6500 (CatOS->IOS) were
> well-executed, customer focused migrations that allowed each to move forward
> without alienating an existing install base and complicating future purchasing
> decisions.

Yes.  Then they split the 6500 and 7600 BUs.  Down the drain goes the
happy customer base.  I think this is really the thing that annoys me
most - they know how to do it right, and conciously decided to go the
other way.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090918/64534fe0/attachment-0001.bin>

From dsavage at castleaccess.com  Fri Sep 18 17:47:50 2009
From: dsavage at castleaccess.com (Denis Savage)
Date: Fri, 18 Sep 2009 14:47:50 -0700
Subject: [c-nsp] Assistance configuring a router to trigger remote
	blackhole
Message-ID: <C6D94E16.3DDE9%dsavage@castleaccess.com>

Did your transit provider give you a community-string to match - usually
their 'AS:arbitrary-number'? Traditionally, what happens is they look for a
BGP community string to match and then accept the null route.

So you have a send-community as a neighbor statement with a route-map and
prefix-list that is sending your normal traffic:

Router bgp (ID)
neighbor (IP) send-community
neighbor (IP) route-map null-routes out
neighbor (IP) prefix-list advertisements out
!
route-map null-routes permit 10
 match interface Null0
 set community (AS):(community-string-to-match)
 route-map null-routes permit 20
!
ip prefix-list advertisements seq 10 permit (block) ge 32
!

Now, when you add a null route using the following, it will automatically
match Null0 and get the BGP-community tag set. It will also allow all other
traffic to pass

ip route (IP) (Subnet Mask) null0


> Naveen Nathan wrote:
>> Hi,
>> 
>> I am new to the list, so please go easy on me.
>> 
>> I'm in need of assistance configuring remote trigger blackhole in
>> IOS. This feature is supported by our transit provider. I'm unsure
>> if it's working or not, but since the nulled routes don't appear to
>> be advertised to the transit peer, I'm assuming not.
>> 
>> I've attached a portion of the cisco-config (substituting sensitive info,
>> but it should be easy enough to follow).
>> 
>> Would someone mind suggesting if I'm missing anything of particular
>> importance. It would be much appreciated.
> 
> If I understand you correctly, wouldn't one need an extra entry in the
> OUTBOUND prefix-list that allows host routes to be advertised to the
> transit?:
> 
> ip bgp-community new-format
> !
> ip prefix-list NULL seq 5 deny 0.0.0.0/0 le 32
> !
> ip prefix-list OUTBOUND seq 5 permit [BLOCK_B]/22
> ip prefix-list OUTBOUND seq 10 permit [BLOCK_C]/22
> ip prefix-list OUTBOUND seq 15 permit [BLOCK_A]/21
> 
> ! just an example for illustration... it looks kind of dangerous
> ip prefix-list OUTBOUND seq 20 permit 0.0.0.0/0 le 32
> 
> Steve
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/x-pkcs7-signature
> Size: 3233 bytes
> Desc: S/MIME Cryptographic Signature
> URL: 
> <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090918/bd4a18be/att
> achment-0001.bin>



From naveen at lastninja.net  Fri Sep 18 18:47:04 2009
From: naveen at lastninja.net (Naveen Nathan)
Date: Fri, 18 Sep 2009 15:47:04 -0700
Subject: [c-nsp] Assistance configuring a router to trigger
	remote	blackhole
In-Reply-To: <4AB3B714.7050207@ibctech.ca>
References: <20090918002313.GB18289@armakuni.lastninja.net>
	<4AB3B714.7050207@ibctech.ca>
Message-ID: <20090918224703.GB22784@armakuni.lastninja.net>

> If I understand you correctly, wouldn't one need an extra entry in the
> OUTBOUND prefix-list that allows host routes to be advertised to the
> transit?:

Steve, that was exactly the problem. I've been meaning to give an update.
Kevin helped me off-list find the issue.

After adding host-routes to OUTBOUND prefix-list, it was advertising.
Then a couple more hours later diddling with the config and skimming
books I realized I needed to include:

ip community-list x:666 standard permit, and then the route-map
began to match the host-routes and advertise to the eBGP peers.

Thanks to everyone that gave input & advice.

-- 
Naveen Nathan

To understand the human mind, understand self-deception. - Anon

From amsoares at netcabo.pt  Fri Sep 18 19:08:09 2009
From: amsoares at netcabo.pt (Antonio Soares)
Date: Sat, 19 Sep 2009 00:08:09 +0100
Subject: [c-nsp] Need help troubleshooting CRC errors
In-Reply-To: <4AB39469.9E6F.00B8.0@dps.k12.oh.us>
References: <4AB211D9.9E6F.00B8.0@dps.k12.oh.us>
	<436848D1ED9646638E260E7AE456D593@int.convex.pt>
	<4AB39469.9E6F.00B8.0@dps.k12.oh.us>
Message-ID: <A596D325B2894B7EA8AE1FFFBE900B7E@int.convex.pt>

This document might help you:

Understanding Maximum Transmission Unit (MTU) on ATM Interfaces

http://www.cisco.com/en/US/tech/tk39/tk371/technologies_tech_note09186a00800c8279.shtml 

This is what it says about Length Violations:

"A router increments the AAL5 length violation counter when the calculated size of a reassembled packet fails to match the received
value of the AAL5 length field regardless of the MTU. To understand how these violations can occur, you need to understand how a
receiving ATM interface recognizes the last cell of a frame."

What ATM NM do you have in the 3640 ? Did you change the default MTU from 4470 to 1500 ?



Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

-----Original Message-----
From: Steven Pfister [mailto:SPfister at dps.k12.oh.us] 
Sent: sexta-feira, 18 de Setembro de 2009 19:09
To: Antonio Soares; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Need help troubleshooting CRC errors

Thanks for the link... I have a little more detail about the problem now:

'show atm pvc x/y' shows:

CrcErrors: 69402, SarTimeOuts: 2, OverSizedSDUs: 0, LengthViolation: 69294, CPIErrors: 0

Also, the router side shows, on 'show int':

  MTU 1500 bytes, sub MTU 1500, BW 155000 Kbit, DLY 80 usec,

router side, on 'show atm int atm':

Max. Datagram Size: 1558

8510 switch side, on 'show int':

  MTU 4470 bytes, sub MTU 4470, BW 155520 Kbit, DLY 0 usec,

Would this be a problem?

Steve Pfister
Technical Coordinator,
The Office of Information Technology
Dayton Public Schools
115 S. Ludlow St. 
Dayton, OH 45402
 
Office (937) 542-3149
Cell (937) 673-6779
Direct Connect: 137*131747*8
Email spfister at dps.k12.oh.us


>>> "Antonio Soares" <amsoares at netcabo.pt> 9/17/2009 11:45 AM >>>
Try this document:

CRC Troubleshooting Guide for ATM Interfaces

http://www.cisco.com/en/US/tech/tk39/tk48/technologies_tech_note09186a00800c93ef.shtml 


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Steven Pfister
Sent: quinta-feira, 17 de Setembro de 2009 15:39
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Need help troubleshooting CRC errors

Some of our older remote sites are connected via ATM. Two or three T1s come into an Cisco 8510, and from there a 155mbps OC3
connection over fiber to a 3640 router. Lately, I've been noticing that pretty much every one of them is showing what I think is a
rather high receive error count on the 3640 end of the OC3 connection, and it all seems to be CRC errors. Not much of any errors are
showing up on the 8510 end of the OC3 connection. For example, one site yesterday late afternoon showed 63, 763 receive errors for
the day. Several others were in the 20Ks. I'm not really certain what the cause might be, or where to start. Can anyone help?

Thanks!


Steve Pfister
Technical Coordinator,
The Office of Information Technology
Dayton Public Schools
115 S. Ludlow St. 
Dayton, OH 45402
 
Office (937) 542-3149
Cell (937) 673-6779
Direct Connect: 137*131747*8
Email spfister at dps.k12.oh.us 


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/ 





From jesus_leung at ahm.honda.com  Fri Sep 18 19:51:15 2009
From: jesus_leung at ahm.honda.com (jesus_leung at ahm.honda.com)
Date: Fri, 18 Sep 2009 16:51:15 -0700
Subject: [c-nsp] CN=Jesus Leung/OU=AHM/OU=AM/O=HONDA is out of the office.
Message-ID: <OFB301E515.D04E8358-ON88257635.00830937-88257635.00830937@ahm.honda.com>


I will be out of the office starting  09/18/2009 and will not return until
09/28/2009.

I will respond to your message when I return. If you require immediate
assistance, please contact Network Operations at 310-783-2518 and someone
will be able to assist you.


From steve at ibctech.ca  Fri Sep 18 20:04:22 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 18 Sep 2009 20:04:22 -0400
Subject: [c-nsp] Assistance configuring a router to trigger
	remote	blackhole
In-Reply-To: <20090918224703.GB22784@armakuni.lastninja.net>
References: <20090918002313.GB18289@armakuni.lastninja.net>
	<4AB3B714.7050207@ibctech.ca>
	<20090918224703.GB22784@armakuni.lastninja.net>
Message-ID: <4AB42006.9070107@ibctech.ca>

Naveen Nathan wrote:
>> If I understand you correctly, wouldn't one need an extra entry in the
>> OUTBOUND prefix-list that allows host routes to be advertised to the
>> transit?:
> 
> Steve, that was exactly the problem. I've been meaning to give an update.
> Kevin helped me off-list find the issue.
> 
> After adding host-routes to OUTBOUND prefix-list, it was advertising.
> Then a couple more hours later diddling with the config and skimming
> books I realized I needed to include:
> 
> ip community-list x:666 standard permit, and then the route-map
> began to match the host-routes and advertise to the eBGP peers.

Glad to hear that you got it working!

Out of curiosity, would you mind sharing the specific pref list entry
you ended up using?

Was it simply 'everything/32'?

Although I have a nice s/RTBH internally, I've never seen/experienced it
done in conjunction with an outside party before.

I'm paranoid about 'accidentally' advertising 'mistakes' to anyone. My
instinct would be to configure or append to a pref-list that
specifically has my_ip_blocks == 32, instead of a blanket allow 32 for all.

If I blackhole/sinkhole an external-to-my-ARIN-block IP that is
attacking my network, I'm deathly afraid that I may accidentally
advertise it to a peer. I *never* assume that my upstream is doing
proper filtering, so I *always* ensure that I can only allow out what I
should be sending out.

Is this paranoia too far fetched?

Steve

ps. Sorry to wane this thread away from it's original intent.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090918/94048186/attachment.bin>

From markom at markom.info  Fri Sep 18 20:13:22 2009
From: markom at markom.info (Marko Milivojevic)
Date: Sat, 19 Sep 2009 00:13:22 +0000
Subject: [c-nsp] 12.2(18)SXD to 12.2(33)SRB|C|D
In-Reply-To: <B32314DD-B600-40F0-A6EE-AD1D1A4736A5@lixfeld.ca>
References: <B32314DD-B600-40F0-A6EE-AD1D1A4736A5@lixfeld.ca>
Message-ID: <d163b99c0909181713p5266ffa4qb5809308afde9fe8@mail.gmail.com>

I know this probably doesn't help you (or anyone on the list), but it
helps my current state of mind about 7600...

The best upgrade path for any 7600 is OFF train.

From naveen at lastninja.net  Fri Sep 18 20:26:16 2009
From: naveen at lastninja.net (Naveen Nathan)
Date: Fri, 18 Sep 2009 17:26:16 -0700
Subject: [c-nsp] Assistance configuring a router to trigger
	remote	blackhole
In-Reply-To: <4AB42006.9070107@ibctech.ca>
References: <20090918002313.GB18289@armakuni.lastninja.net>
	<4AB3B714.7050207@ibctech.ca>
	<20090918224703.GB22784@armakuni.lastninja.net>
	<4AB42006.9070107@ibctech.ca>
Message-ID: <20090919002616.GB6822@armakuni.lastninja.net>

> Glad to hear that you got it working!

Thanks.

> Out of curiosity, would you mind sharing the specific pref list entry
> you ended up using?
> 
> Was it simply 'everything/32'?

Tinkering with the prefix-list at first, got the results I expected.
I was redistributing the static routes to BGP, matching on tag and
applying matched routes with a community string.

However since the newly injected routes weren't advertising to eBGP peers,
I explicitly added the host routes to OUTBOUND prefix-list, and everything
started to work. This lead me to believe that the OUTBOUND route-map that
matches on the community string was ineffective. Also, the administrative
hassle of adding the static route and including it in the prefix-list
I found is unacceptable.

I reverted the configuration and focused my efforts on debugging the
route-map that matched on community string. I realized I missed a crucial
statement, ip community-list ... x:666 permit. After tweaking around I
came up with the following changes to the original configuration that
appears to work properly, and doesn't require any modifications of
the OUTBOUND prefix-list (not shown):

ip community-list standard BLACKHOLE permit 27524:666

route-map OUTBOUND permit 100
 description Deny Null Routes
 match community BLACKHOLE
!
route-map OUTBOUND permit 110
 description Allow internal routes
 match ip address prefix-list OUTBOUND
!
route-map STATIC-TO-BGP permit 50
 description Upstream Blackhole
 match tag 666
 set community [UPSTREAM_AS]:666
!

> Although I have a nice s/RTBH internally, I've never seen/experienced it
> done in conjunction with an outside party before.

I noticed a lot of the docs discuss using RTBH intra-AS, so that edge
routers discard the packets. I come from the opposite side since I've
only worked on smaller networks where there's only one edge that is
single/multi-homed. Large providers such as Level3 usually offer
a blackhole community where you can blackhole routes for blocks that
you advertise.

> I'm paranoid about 'accidentally' advertising 'mistakes' to anyone. My
> instinct would be to configure or append to a pref-list that
> specifically has my_ip_blocks == 32, instead of a blanket allow 32 for all.

I think maintaining the prefix-list and static routes will lead to errors,
so that's why I went w/ the former option of matching on community string.

> If I blackhole/sinkhole an external-to-my-ARIN-block IP that is
> attacking my network, I'm deathly afraid that I may accidentally
> advertise it to a peer. I *never* assume that my upstream is doing
> proper filtering, so I *always* ensure that I can only allow out what I
> should be sending out.
> 
> Is this paranoia too far fetched?

I'm not too experienced with provider mishaps, but I think most providers
esp. in the case of RTBH only allow for routes that belong to your own
blocks. I take for granted that the provider does proper filtering,
especially for the case of RTBH.

Hope the above helps.

From justin at justinshore.com  Fri Sep 18 20:41:01 2009
From: justin at justinshore.com (Justin Shore)
Date: Fri, 18 Sep 2009 19:41:01 -0500
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AAFD139.4050402@west.net>
References: <4AAFD139.4050402@west.net>
Message-ID: <4AB4289D.4070301@justinshore.com>

Jay Hennigan wrote:
> What the #$^&$@# is going on with Cisco's download site?  It completely 
> hangs Firefox with some shopping cart java thing.  And this is downright 
> scary:  http://www.west.net/~jay/images/cisco-wants-root.png
> 
> Enhanced downloads, brought to you by the same people who brought us 
> enhanced interrogation?
> 
> Is there a workaround?  What happened to our friend kobayashi ?

I have a solution.  Each and every time you want an IOS image contact 
your account team and ask them to send it to you.  Do this every single 
time you need an image.  When I'm upgrading code I may do this for a 
dozen different models in a given day.  Don't forget the FPM, bootroms, 
etc.  Annoy the living shit out of your account team and let THEM put 
the pressure on the fucknuts who run cisco.com.  It's clear that they 
could care less what we customers think.  Perhaps if their own coworkers 
bitch and moan about being made to do additional work something might 
change.

Justin




From justin at justinshore.com  Fri Sep 18 20:55:09 2009
From: justin at justinshore.com (Justin Shore)
Date: Fri, 18 Sep 2009 19:55:09 -0500
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <54B74A52-F9EC-47DD-92F9-97913A7026D7@wisc.edu>
References: <4AAFD139.4050402@west.net>
	<54B74A52-F9EC-47DD-92F9-97913A7026D7@wisc.edu>
Message-ID: <4AB42BED.9070208@justinshore.com>

Dale W. Carder wrote:
>> Is there a workaround?
> 
> I found a workaround.  I couldn't download a file due to
> some stupid java error, so I opened a tac case for them
> to give me the file.
> 
> Maybe after this happens enough times and costs them real
> money it will get fixed.

That's even better than my idea of asking your account team to get you 
the files.  Genius!  I feel a rash of network upgrades coming next week. 
    Unfortunately I'm afraid that I may be forced to open several TAC 
cases to support my needs.  Pity.

Justin




From john at vanoppen.com  Fri Sep 18 21:22:54 2009
From: john at vanoppen.com (John van Oppen)
Date: Fri, 18 Sep 2009 18:22:54 -0700
Subject: [c-nsp] "Enhanced" download procedure
References: <4AAFD139.4050402@west.net><54B74A52-F9EC-47DD-92F9-97913A7026D7@wisc.edu>
	<4AB42BED.9070208@justinshore.com>
Message-ID: <DB9EA494D2E5614D842C2BC65C2D172288C951@mail-ww.vanoppen.com>

Yep, that was like my brute force solution to the one upstream of mine
that does not support RADB based filters, I have cron sending updates to
their support@ email address automatically on my behalf...   I even got
a call back from a senior person there after that went on for about a
month as I was apparently causing nearly daily updates (we have about 70
ASNs downstream)...   Good times.

I could not agree with Justin more that the best way to fix such issues
is to cause the annoying "feature" to be painful for people within the
organization responsible for the annoying feature. 


John van Oppen
Spectrum Networks LLC
Direct: 206.973.8302
Main: 206.973.8300
Website: http://spectrumnetworks.us


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Justin Shore
Sent: Friday, September 18, 2009 5:55 PM
To: Dale W. Carder
Cc: Cisco Mailing list
Subject: Re: [c-nsp] "Enhanced" download procedure

Dale W. Carder wrote:
>> Is there a workaround?
> 
> I found a workaround.  I couldn't download a file due to
> some stupid java error, so I opened a tac case for them
> to give me the file.
> 
> Maybe after this happens enough times and costs them real
> money it will get fixed.

That's even better than my idea of asking your account team to get you 
the files.  Genius!  I feel a rash of network upgrades coming next week.

    Unfortunately I'm afraid that I may be forced to open several TAC 
cases to support my needs.  Pity.

Justin



_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From judah.scott.iam at gmail.com  Fri Sep 18 21:34:41 2009
From: judah.scott.iam at gmail.com (Judah Scott)
Date: Fri, 18 Sep 2009 18:34:41 -0700
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AB42BED.9070208@justinshore.com>
References: <4AAFD139.4050402@west.net>
	<54B74A52-F9EC-47DD-92F9-97913A7026D7@wisc.edu>
	<4AB42BED.9070208@justinshore.com>
Message-ID: <3172b9cb0909181834q272f0ef1jd45a84966e42fdbb@mail.gmail.com>

I don't know if this will push Cisco.  My experiences with TAC suggest that
they could throw several people on the job of ftp'ing files full time and it
would only lead to their competent TAC people solving real problems quicker;
one would no longer need to escalate every case immediately to get past the
incompetent levels.

On second thought, this is a win-win.

-J Scott


On Fri, Sep 18, 2009 at 5:55 PM, Justin Shore <justin at justinshore.com>wrote:

> Dale W. Carder wrote:
>
>> Is there a workaround?
>>>
>>
>> I found a workaround.  I couldn't download a file due to
>> some stupid java error, so I opened a tac case for them
>> to give me the file.
>>
>> Maybe after this happens enough times and costs them real
>> money it will get fixed.
>>
>
> That's even better than my idea of asking your account team to get you the
> files.  Genius!  I feel a rash of network upgrades coming next week.
> Unfortunately I'm afraid that I may be forced to open several TAC cases to
> support my needs.  Pity.
>
> Justin
>
>
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From mylists at battleop.com  Fri Sep 18 22:32:59 2009
From: mylists at battleop.com (Richey)
Date: Fri, 18 Sep 2009 22:32:59 -0400
Subject: [c-nsp] Metro E best practices
Message-ID: <019401ca38d1$8269e9e0$873dbda0$@com>

We are a small provider that's going to start offering access to customers
over AT&T's Premium Metro E product.    Can someone share some best
practices and maybe some config pointers?  I've not make a decision on what
router to use on our end that we will bring remote sites back to.   I have
some 3660s and 7206s that are doing nothing and thought one of the two would
make a decent router to start with.   

 

 

Richey

 

 


From graham at g-rock.net  Fri Sep 18 22:00:06 2009
From: graham at g-rock.net (Graham Wooden)
Date: Fri, 18 Sep 2009 21:00:06 -0500
Subject: [c-nsp] Gut check needed - QoS
Message-ID: <C6D9A556.A654%graham@g-rock.net>

Hi all,

Paul?s email from yesterday regarding QoS on a T1 link got me thinking about
a recently deployed PtP T1 serving the same purpose, data/voip to a
customer.  The routers involved on each side are not fancy; my T1 edge is a
2621 and the CPE is a 1760.  The 2621 is hanging off of my 6500/Sup32 that
handles my core stuff.  My softswitches are hanging off of the same chassis.
The CPE 1760 is plugged into switch that has a PIX and a Linksys SPA8000
ATA.

Below is what I had deployed. Pauls email from yesterday and talking with a
good friend earlier confirmed some of this. I reviewed
http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080
103eae.shtml to double check the use between ?priority? and ?bandwidth?.
Priority appears to be a better fit.  Both sides have the same config
applied.  

Does anyone see anything wrong?  I am not 100% sure on the ?ip route-cache
policy? under the serial 0/0. I don?t see it too often in other configs and
examples.  While this particular ATA does the RTP in a smaller port range, I
like the ACL ranges as I have started to deploy this in other situations
(where RTP is very random between ports 10K and 20K).  And lastly, Is it
safe to assume that the class-default will have access to the full T1 until
calls start rolling through?

TIA,

-graham

-----
class-map match-any VOIP
  description "Prioritize SIP and RTP"
 match access-group 101
!
policy-map VOIP
 class VOIP
  priority percent 50
 class class-default
  fair-queue
!
interface Serial0/0
 bandwidth 1536
 ip address n.n.n.n 255.255.255.252
 no ip unreachables
 no ip proxy-arp
 ip route-cache policy
 no ip mroute-cache
 load-interval 30
 service-module t1 cablelength short 110ft
 service-module t1 timeslots 1-24
 service-policy output VOIP
!
access-list 101 permit udp any any range 4000 5999
access-list 101 permit udp any any range 10000 20000

From steve at ibctech.ca  Fri Sep 18 23:45:12 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 18 Sep 2009 23:45:12 -0400
Subject: [c-nsp] Metro E best practices
In-Reply-To: <019401ca38d1$8269e9e0$873dbda0$@com>
References: <019401ca38d1$8269e9e0$873dbda0$@com>
Message-ID: <4AB453C8.8040908@ibctech.ca>

Richey wrote:
> We are a small provider that's going to start offering access to customers
> over AT&T's Premium Metro E product.    Can someone share some best
> practices and maybe some config pointers?  I've not make a decision on what
> router to use on our end that we will bring remote sites back to.   I have
> some 3660s and 7206s that are doing nothing and thought one of the two would
> make a decent router to start with.   

Heh. Seriously?

Not only are you advertising your one-and-only wholesaler, but you are
asking for configuration help on devices "that are doing nothing" for
use as infrastructure gear.

This is what I heard you say:

- I'm an ISP
- I don't know what I'm doing
- pay me money to connect, I have a good upstream
- my hardware is used, but since I don't know how to work it, it's even
more useless than it normally would be

There are many, many best practises, many which will turn up in the
archives.

I'm sure you are interested in tra......

...forget it. I try too hard and get nowhere, and then have ISPs pop up
everywhere who just don't seem to care.

Steve

ps. If you really do care and I mistook your blob of a message for
something else, I apologize.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090918/b906c07a/attachment.bin>

From kgraham at industrial-marshmallow.com  Fri Sep 18 23:52:32 2009
From: kgraham at industrial-marshmallow.com (Kevin Graham)
Date: Fri, 18 Sep 2009 20:52:32 -0700 (PDT)
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <20090918210430.GY1508@greenie.muc.de>
References: <4AA8E79E.2030109@sara.nl> <20090910121617.GH1508@greenie.muc.de>
	<373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>
	<CD0195AB-DF6F-4B41-83BD-0E6F5F0BADF9@puck.nether.net>
	<20090914143623.GE1508@greenie.muc.de>
	<20090914163011.GC25690@lboro.ac.uk>
	<20090916080639.GX1508@greenie.muc.de>
	<0E0ADFB3-3D29-4857-B6B4-92E8698B026E@hughes.com.au>
	<alpine.WNT.2.00.0909171006020.3984@pckoug1.intranet.gr>
	<412409.56453.qm@web1206.biz.mail.gq1.yahoo.com>
	<20090918210430.GY1508@greenie.muc.de>
Message-ID: <2716.29557.qm@web1202.biz.mail.gq1.yahoo.com>


> I think this is really the thing that annoys me most - they know how
> to do it right, and conciously decided to go the other way.

Yep. The single biggest reason I'm not advocating Nexus 5000/7000's today
is the lack of NX-OS on the Sup720. If there was roadmap for it to also
include existing DSBU hardware in the 'FEX' role, I would be implementing
fervently, ignoring every missing feature that wasn't absolutely critical
to passing packets.

> Then they split the 6500 and 7600 BUs.  Down the drain goes the happy

> customer base.

All of which could be forgiven 20 times over had the plan been to have
7600/XE with EARL taking the place of QFP, allowing the 7600 to be the
brutish dumb big brother to the ASR1k.

Sorry, the thought of being able to plan forward-looking purchases and
technology migrations this beautifully makes me tingly... _These_ 
would be the moves of a dominant market leader with a rich innovative
history. Thankfully there's a weekend ahead before it has to crash
back down again.


From kgraham at industrial-marshmallow.com  Fri Sep 18 23:58:10 2009
From: kgraham at industrial-marshmallow.com (Kevin Graham)
Date: Fri, 18 Sep 2009 20:58:10 -0700 (PDT)
Subject: [c-nsp] Assistance configuring a router to trigger remote
	blackhole
In-Reply-To: <4AB42006.9070107@ibctech.ca>
References: <20090918002313.GB18289@armakuni.lastninja.net>
	<4AB3B714.7050207@ibctech.ca>
	<20090918224703.GB22784@armakuni.lastninja.net>
	<4AB42006.9070107@ibctech.ca>
Message-ID: <684925.53599.qm@web1211.biz.mail.gq1.yahoo.com>

> If I blackhole/sinkhole an external-to-my-ARIN-block IP that is

> attacking my network, I'm deathly afraid that I may accidentally
> advertise it to a peer.

Hadn't thought about it, but yeah, requiring a very long prefix
length before appending RTBH prefixes would be a good safety 
measure.

> I *never* assume that my upstream is doing proper filtering, so
> I *always* ensure that I can only allow out what I should be
> sending out.
> 
> Is this paranoia too far fetched?

Nope. Even with 'good' route-maps in place, a 'prefix-list out'
directly on the neighbor still makes be feel good. (Similarly,
as a stub network, we always add no-exports for imports from
all eBGP sessions as well).


From kgraham at industrial-marshmallow.com  Sat Sep 19 00:07:16 2009
From: kgraham at industrial-marshmallow.com (Kevin Graham)
Date: Fri, 18 Sep 2009 21:07:16 -0700 (PDT)
Subject: [c-nsp] BGP and remote POPs with individual upstreams
In-Reply-To: <d066472f0909181347v1a7614b0p578b9d65bd1ae1bf@mail.gmail.com>
References: <d066472f0909181347v1a7614b0p578b9d65bd1ae1bf@mail.gmail.com>
Message-ID: <716749.35098.qm@web1216.biz.mail.gq1.yahoo.com>

> My initial thoughts are to BGP peer between POPs with a higher local-pref

> for the local outbound traffic and to prepend between the POPs so inbound
> traffic is more likely to take the shortest path inbound.
>
> Is this too simplistic? Prone to trouble? What gotchas should I be looking
> at, or other designs should I be considering?

This is entirely reasonable. If you wanted, you could also look at doing
each POP as a federation, which would get similar results as well.

For egress traffic with different transit providers, you'll inevitably still
leak some traffic between POP's with more-specifics learned via a single
provider, but this should be small.

An AS-prepend of non-local-prefixes would take care of ingress reasonably
(again, expect some small surprises), though if you have the same provider
to multiple POPs, you could also get there w/ just MED's.

>  My Cisco bookshelf isn't helping me much with this...

Add Internet Routing Architectures to it then, it is well worth the read.


From blocke at newpaltz.edu  Sat Sep 19 03:46:24 2009
From: blocke at newpaltz.edu (Bruce A. Locke)
Date: Sat, 19 Sep 2009 03:46:24 -0400 (EDT)
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <3172b9cb0909181834q272f0ef1jd45a84966e42fdbb@mail.gmail.com>
Message-ID: <2109567551.1635981253346384798.JavaMail.root@zmail.newpaltz.edu>


The following might be of interest as a workaround.

Create a bookmark in your favorite browser and add the following in the Location/URL field (all as one line):

javascript:eval('dlf_cart=' + cartData); for (dlf_i = 0; dlf_i < dlf_cart["goodCartContent"].length; dlf_i++) {dlf_curcartpos = dlf_cart["goodCartContent"][dlf_i]; dlf_cururl = "http://" + dlf_curcartpos["ftpServerName"] + dlf_curcartpos["filePath"] + "/" + dlf_curcartpos["fileName"]; document.write("<a href=\"" + dlf_cururl + "\">" + dlf_cururl + "</a><br/>");}

I've done some light testing on Firefox 3.5 and it seems to work for me.

Use this bookmark on the "Download Software" page that says "If your download does not start, click here".   It's the page you see in your main browser window that then causes Firefox to whine about the popup its trying to open with the java applet.

As has been pointed out previously the information needed to construct a direct HTTP link is embedded in that page which is passed to the java applet.  This bookmark script just extracts that and prints the direct links.  In other words, it took me 15 minutes of learning javascript from quick Google queries to get done what Cisco could do themselves.

Enjoy your weekend everyone.


-- 
Bruce A. Locke
blocke at newpaltz.edu
HAB 50 - (845) 257-3809

Network Administrator
Computer Services
State University of New York at New Paltz 


From avayner at cisco.com  Sat Sep 19 05:49:06 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Sat, 19 Sep 2009 11:49:06 +0200
Subject: [c-nsp] Graphing specefic traffic
In-Reply-To: <BLU102-W2927BD80F06C370B2A1AE4FAE10@phx.gbl>
References: <BLU102-W28B6DAC3DB0E5E42D0C72BFAE10@phx.gbl>
	<FDD1CDB3FB499E4087CC7670BBCA22C6446DF5@XMB-AMS-101.cisco.com>
	<BLU102-W2927BD80F06C370B2A1AE4FAE10@phx.gbl>
Message-ID: <FDD1CDB3FB499E4087CC7670BBCA22C64A3721@XMB-AMS-101.cisco.com>

Then if this is for short term, why not just use a sniffer?

Arie

 

From: Mohammad Khalil [mailto:eng_mssk at hotmail.com] 
Sent: Thursday, September 17, 2009 18:58
To: Arie Vayner (avayner); cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Graphing specefic traffic

 

No Arie its a short term but it would be useful if it can be done on the
long term

> Subject: RE: [c-nsp] Graphing specefic traffic
> Date: Thu, 17 Sep 2009 15:40:01 +0200
> From: avayner at cisco.com
> To: eng_mssk at hotmail.com; cisco-nsp at puck.nether.net
> 
> Mohammad,
> 
> Is this for long term reporting or for short term troubleshooting?
> 
> Thanks
> Arie
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mohammad
Khalil
> Sent: Thursday, September 17, 2009 16:00
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Graphing specefic traffic
> 
> 
> hey all
> 
> i have a 7600 cisco router and i have customers terminated to it
> (ethernet)
> for example one of the customers is consuming SIP , i want to be able
to
> graph this traffic (SIP) for that certain user
> can i do that ??
> no SCE to be used :)
> 
> _________________________________________________________________
> With Windows Live, you can organize, edit, and share your photos.
>
http://www.microsoft.com/middleeast/windows/windowslive/products/photo-g
> allery-edit.aspx
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

________________________________

See all the ways you can stay connected to friends and family
<http://www.microsoft.com/windows/windowslive/default.aspx> 


From paul at paulstewart.org  Sat Sep 19 08:31:20 2009
From: paul at paulstewart.org (Paul Stewart)
Date: Sat, 19 Sep 2009 08:31:20 -0400
Subject: [c-nsp] Gut check needed - QoS
In-Reply-To: <C6D9A556.A654%graham@g-rock.net>
References: <C6D9A556.A654%graham@g-rock.net>
Message-ID: <003701ca3925$19495550$4bdbfff0$@org>

Hi Graham...

That should work just fine...  One minor thing to note by matching UDP port
ranges.. any traffic (not just RTP) that hits those ranges will get priority
.. typically not a big thing but worth mentioning.  In my earlier posting, I
was actually matching by the IP blocks where the softswitch platform
(Metaswitch) is deployed vs port ranges.

Priority will only use bandwidth as it requires it so yes, the default class
will have access to all the bandwidth until something "prioritized" needs
it....

Hope this helps...

Paul


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Graham Wooden
Sent: September 18, 2009 10:00 PM
To: cisco-nsp
Subject: [c-nsp] Gut check needed - QoS

Hi all,

Paul?s email from yesterday regarding QoS on a T1 link got me thinking about
a recently deployed PtP T1 serving the same purpose, data/voip to a
customer.  The routers involved on each side are not fancy; my T1 edge is a
2621 and the CPE is a 1760.  The 2621 is hanging off of my 6500/Sup32 that
handles my core stuff.  My softswitches are hanging off of the same chassis.
The CPE 1760 is plugged into switch that has a PIX and a Linksys SPA8000
ATA.

Below is what I had deployed. Pauls email from yesterday and talking with a
good friend earlier confirmed some of this. I reviewed
http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080
103eae.shtml to double check the use between ?priority? and ?bandwidth?.
Priority appears to be a better fit.  Both sides have the same config
applied.  

Does anyone see anything wrong?  I am not 100% sure on the ?ip route-cache
policy? under the serial 0/0. I don?t see it too often in other configs and
examples.  While this particular ATA does the RTP in a smaller port range, I
like the ACL ranges as I have started to deploy this in other situations
(where RTP is very random between ports 10K and 20K).  And lastly, Is it
safe to assume that the class-default will have access to the full T1 until
calls start rolling through?

TIA,

-graham

-----
class-map match-any VOIP
  description "Prioritize SIP and RTP"
 match access-group 101
!
policy-map VOIP
 class VOIP
  priority percent 50
 class class-default
  fair-queue
!
interface Serial0/0
 bandwidth 1536
 ip address n.n.n.n 255.255.255.252
 no ip unreachables
 no ip proxy-arp
 ip route-cache policy
 no ip mroute-cache
 load-interval 30
 service-module t1 cablelength short 110ft
 service-module t1 timeslots 1-24
 service-policy output VOIP
!
access-list 101 permit udp any any range 4000 5999
access-list 101 permit udp any any range 10000 20000
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From james.brown at rpmconsultants.co.uk  Sat Sep 19 08:52:35 2009
From: james.brown at rpmconsultants.co.uk (James Brown)
Date: Sat, 19 Sep 2009 13:52:35 +0100
Subject: [c-nsp] max-reserved-bandwidth question
Message-ID: <4AB4D413.9030905@rpmconsultants.co.uk>

All,

I realise there are more posts out there about max-reserved-bandwidth 
than you can shake a stick at, but could anyone help me with this please...?

Does the 25% only kick in during times of congestion, and which traffic 
does it really contain? I'm using 12.4 Mainline and if several sources 
are to be believed I have reason to think that 25% of the bandwidth is 
hived off all the time, never to be seen again unless you set 
max-reserved-bandwidth to 100%. Can that really be true? I would have 
expected the 25% 'hidden' queue to only be serviced when there are heaps 
of routing updates waiting to use a congested interface.

What I'm trying to achieve is to set all DSCP values to zero, but not 
starve routing updates in the process. In which case, how well would 
this policy work?

!
class-map match-all CM-ALL
  match any
!
service-policy PM-BLEACH
  class CM-ALL
   set ip dscp default
!
inter serial1/0
  max-reserved-bandwidth 100
  service-policy out PM-BLEACH
!

Have I just un-prioritised routing updates by removing the 25% 'hidden' 
queue? Do I need to then create a "class-default" within PM-BLEACH and 
allocate bandwidth 25?

Any advice on this would be really appreciated and help answer a 
question I just can't seem to find and answer to online.

Many thanks

James.

From mylists at battleop.com  Sat Sep 19 10:55:10 2009
From: mylists at battleop.com (Richey)
Date: Sat, 19 Sep 2009 10:55:10 -0400
Subject: [c-nsp] Metro E best practices
In-Reply-To: <4AB453C8.8040908@ibctech.ca>
References: <019401ca38d1$8269e9e0$873dbda0$@com> <4AB453C8.8040908@ibctech.ca>
Message-ID: <021101ca3939$2fdf4180$8f9dc480$@com>

Wow, I bet that made you feel strong and powerful.  I did some searches but
most everything I keep turning up is marketing speak.  As to re-tasking some
routers that are no longer in use, are you kidding me?  Am I the only one
that finds it wasteful to take a perfectly good box and change it's role?
Shame on us for not spending money like a dot bomb...

I was looking for some best practices, not how to do it,  hence the "Best
Practices" and not "How do I setup a metro e from scratch?"

"Not only are you advertising your one-and-only wholesaler"

It does not take rocket science to figure out if a provider is using the LEC
as their Metro E transport.  

Richey

-----Original Message-----
From: Steve Bertrand [mailto:steve at ibctech.ca] 
Sent: Friday, September 18, 2009 11:45 PM
To: Richey
Cc: 'Cisco Mailing list'
Subject: Re: [c-nsp] Metro E best practices

Richey wrote:
> We are a small provider that's going to start offering access to customers
> over AT&T's Premium Metro E product.    Can someone share some best
> practices and maybe some config pointers?  I've not make a decision on
what
> router to use on our end that we will bring remote sites back to.   I have
> some 3660s and 7206s that are doing nothing and thought one of the two
would
> make a decent router to start with.   

Heh. Seriously?

Not only are you advertising your one-and-only wholesaler, but you are
asking for configuration help on devices "that are doing nothing" for
use as infrastructure gear.

This is what I heard you say:

- I'm an ISP
- I don't know what I'm doing
- pay me money to connect, I have a good upstream
- my hardware is used, but since I don't know how to work it, it's even
more useless than it normally would be

There are many, many best practises, many which will turn up in the
archives.

I'm sure you are interested in tra......

...forget it. I try too hard and get nowhere, and then have ISPs pop up
everywhere who just don't seem to care.

Steve

ps. If you really do care and I mistook your blob of a message for
something else, I apologize.


From teddy.asrat at africaonline.co.sz  Sat Sep 19 10:38:05 2009
From: teddy.asrat at africaonline.co.sz (Teddy A.)
Date: Sat, 19 Sep 2009 16:38:05 +0200
Subject: [c-nsp] CISCO SOHO 96 ISDN Issue
Message-ID: <000701ca3936$ce4d7380$6ae85a80$@asrat@africaonline.co.sz>

Good Day,

 

I have a problem with a client's CISCO SOHO 96 router, it is supposed to be
used for ISDN DOD (Dial On Demand), but the problem is the ADSL RXD and TXD
link light keep blinking and I get the following log on the console:

 

DSL: connection has reached max retries toggle to other mode

 

The configurations for the router is exactly the same as other clients using
the system, the only difference being that the other routers do not have
ADSL ports. The router doesn't even send authentication packets to the
RADUIS server. I have tried downloading the latest firmware from CISCO and
flashing the router with it, but as soon as the router has finished loading
and it gets to the Press Return To Get Started prompt those two ASDSL RXD
and TXD start flickering simultaneously.

 

I am starting to think it might be a hardware problem, but I wanted to know
if anyone else has experienced the same problem, and if they ever managed to
sort it out. 

 

Thank you.

 

Kind Regards,

 

Teddy A.
Network Engineer,

Africa Online



 


From gert at greenie.muc.de  Sat Sep 19 12:26:06 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Sat, 19 Sep 2009 18:26:06 +0200
Subject: [c-nsp] Need help troubleshooting CRC errors
In-Reply-To: <4AB211D9.9E6F.00B8.0@dps.k12.oh.us>
References: <4AB211D9.9E6F.00B8.0@dps.k12.oh.us>
Message-ID: <20090919162606.GE1508@greenie.muc.de>

Hi,

On Thu, Sep 17, 2009 at 10:39:21AM -0400, Steven Pfister wrote:
> that pretty much every one of them is showing what I think is a
> rather high receive error count on the 3640 end of the OC3 connection,
> and it all seems to be CRC errors. Not much of any errors are
> showing up on the 8510 end of the OC3 connection. For example, one
> site yesterday late afternoon showed 63, 763 receive errors for
> the day. Several others were in the 20Ks. I'm not really certain
> what the cause might be, or where to start. Can anyone help?

Is there a carrier network in between?  In our cases, whenever we saw
ATM CRC errors, it was due to dropped cells in the carrier network
(overloaded).  If the receiving router cannot reassemble a packet due
to missing cells -> CRC error.

If the STM-1 is "direct", no carrier ATM gear in between (just SDH/SONET)
gear, it be a bad line.   In that case it won't be cell drops.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090919/e2ea5d4f/attachment.bin>

From graham at g-rock.net  Sat Sep 19 12:27:57 2009
From: graham at g-rock.net (Graham Wooden)
Date: Sat, 19 Sep 2009 11:27:57 -0500
Subject: [c-nsp] Gut check needed - QoS
In-Reply-To: <003701ca3925$19495550$4bdbfff0$@org>
Message-ID: <C6DA70BD.A693%graham@g-rock.net>

Hey there Paul,

I have considered that, but I do have some clients that are not on my voice
platform (yet) and I need to match by ports. With RTP being mostly in that
range, I needed to cover all my boxes as I have some that NBAR doesn't seem
to work. So you can see my dilemma with that as I wanted to standardize on
one setup oppose to have several different tweaks out there ...

I will have to keep a close eye out on the policy-map stats and maybe
ultimately saying "screw it" and match to the voice switch VLAN.

Thanks again for the reply and re-assurance.

-graham


On 9/19/09 7:31 AM, "Paul Stewart" <paul at paulstewart.org> wrote:

> Hi Graham...

That should work just fine...  One minor thing to note by
> matching UDP port
ranges.. any traffic (not just RTP) that hits those ranges
> will get priority
.. typically not a big thing but worth mentioning.  In my
> earlier posting, I
was actually matching by the IP blocks where the softswitch
> platform
(Metaswitch) is deployed vs port ranges.

Priority will only use
> bandwidth as it requires it so yes, the default class
will have access to all
> the bandwidth until something "prioritized" needs
it....

Hope this
> helps...

Paul


-----Original Message-----
From:
> cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net]
> On Behalf Of Graham Wooden
Sent: September 18, 2009 10:00 PM
To:
> cisco-nsp
Subject: [c-nsp] Gut check needed - QoS

Hi all,

Paul?s email from
> yesterday regarding QoS on a T1 link got me thinking about
a recently deployed
> PtP T1 serving the same purpose, data/voip to a
customer.  The routers
> involved on each side are not fancy; my T1 edge is a
2621 and the CPE is a
> 1760.  The 2621 is hanging off of my 6500/Sup32 that
handles my core stuff.
> My softswitches are hanging off of the same chassis.
The CPE 1760 is plugged
> into switch that has a PIX and a Linksys SPA8000
ATA.

Below is what I had
> deployed. Pauls email from yesterday and talking with a
good friend earlier
> confirmed some of this. I
> reviewed
http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note091
> 86a0080
103eae.shtml to double check the use between ?priority? and
> ?bandwidth?.
Priority appears to be a better fit.  Both sides have the same
> config
applied.  

Does anyone see anything wrong?  I am not 100% sure on the
> ?ip route-cache
policy? under the serial 0/0. I don?t see it too often in
> other configs and
examples.  While this particular ATA does the RTP in a
> smaller port range, I
like the ACL ranges as I have started to deploy this in
> other situations
(where RTP is very random between ports 10K and 20K).  And
> lastly, Is it
safe to assume that the class-default will have access to the
> full T1 until
calls start rolling through?

TIA,

-graham

-----
class-map
> match-any VOIP
  description "Prioritize SIP and RTP"
 match access-group
> 101
!
policy-map VOIP
 class VOIP
  priority percent 50
 class class-default

> fair-queue
!
interface Serial0/0
 bandwidth 1536
 ip address n.n.n.n
> 255.255.255.252
 no ip unreachables
 no ip proxy-arp
 ip route-cache policy

> no ip mroute-cache
 load-interval 30
 service-module t1 cablelength short
> 110ft
 service-module t1 timeslots 1-24
 service-policy output
> VOIP
!
access-list 101 permit udp any any range 4000 5999
access-list 101
> permit udp any any range 10000
> 20000
_______________________________________________
cisco-nsp mailing list
> cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
a
> rchive at 
> http://puck.nether.net/pipermail/cisco-nsp/

_________________________________
> ______________
cisco-nsp mailing list
> cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
a
> rchive at http://puck.nether.net/pipermail/cisco-nsp/



From erpa22276 at yahoo.com  Sat Sep 19 12:37:41 2009
From: erpa22276 at yahoo.com (Per A)
Date: Sat, 19 Sep 2009 09:37:41 -0700 (PDT)
Subject: [c-nsp] CSS Operation description needed
Message-ID: <173690.88515.qm@web36203.mail.mud.yahoo.com>

Sorry for the false-start.
?
I have an emergency request for CSS config and practically no exposure to this platform.
?
General description:? customer has web server that can't handle load.? Server resides in DMZ where ASA provides access and NAT conversion to private address.? To reduce the amount of traffic the original server gets, the customer wants to send requests destined for one directory within the url path to a new server, all other requests to the orignal server. 
?
Here is a link I found providing a configuration example on how to do this:? http://www.cisco.com/en/US/products/hw/contnetw/ps792/products_configuration_example09186a00801c0dbc.shtml
?
So, what I'm looking for is a high level description of the operational path that CSS uses to make this kind of function work.
?
Here is my speculation based on what I've read:? I will change the NAT on the ASA to point traffic?for this website to the CSS server.? The CSS server accept the TCP session on behalf of the web server,?inspect the HTML GET request to determine the "routing" path and then generate a request to the appropriate HTTP server and pass the response back to the original client, thus proxying the entire conversation.? The CSS server would need an IP address in the DMZ and a?port attached in that network, and a default route.
?
Is it that simple?

Thanks in advance for your help (especially on Saturday)!
?
?


      

From erpa22276 at yahoo.com  Sat Sep 19 12:25:00 2009
From: erpa22276 at yahoo.com (Per A)
Date: Sat, 19 Sep 2009 09:25:00 -0700 (PDT)
Subject: [c-nsp] CSS Operation description needed
Message-ID: <250832.82568.qm@web36203.mail.mud.yahoo.com>

I 


      

From Stig.Johansen at atea.no  Sat Sep 19 19:33:27 2009
From: Stig.Johansen at atea.no (Stig Johansen)
Date: Sun, 20 Sep 2009 01:33:27 +0200
Subject: [c-nsp] "Enhanced" download procedure - better workaround,
 for some :)
In-Reply-To: <D49C1A85-BB57-42E0-8301-472E1A83A91E@puck.nether.net>
References: <98424577.1493471253223622619.JavaMail.root@zmail.newpaltz.edu>
	<alpine.BSF.2.00.0909181456280.34749@murf.icantclick.org>
	<D49C1A85-BB57-42E0-8301-472E1A83A91E@puck.nether.net>
Message-ID: <5EB9799F396A304686962AFFF740ED0C0168362530@NOOSLEXCH001.adno.local>

Jared Mauch wrote:
>fileName":"s72033-advipservicesk9-mz.122-33.SXI2a.bin"
>filePath":"/swc/esd/03/crypto/3DES/281569550/contract"
>ftpServerName":"download-sj.cisco.com"

I was working on a greasemonkey-script for emulating the Java-applet, but hit a couple of snags concerning binary output, so I did some more digging after seeing this post and I discovered that all the goodies are right there even when you are just looking at the download-cart without even pressing the "Proceed with download"-button.

I then chose to make a greasemonkey-script to use this info (in a somewhat similar way to what Bruce A. Locke did in his little javascript) and present it on the downloadcart-page itself.

http://userscripts.org/scripts/show/58082

/Stig

From steve at ibctech.ca  Sat Sep 19 19:50:46 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Sat, 19 Sep 2009 19:50:46 -0400
Subject: [c-nsp] Metro E best practices
In-Reply-To: <021101ca3939$2fdf4180$8f9dc480$@com>
References: <019401ca38d1$8269e9e0$873dbda0$@com> <4AB453C8.8040908@ibctech.ca>
	<021101ca3939$2fdf4180$8f9dc480$@com>
Message-ID: <4AB56E56.9020005@ibctech.ca>

Richey, I am very sorry. My response is not typical of my normal actions.

I've had a significant tragedy happen, and I completely took it out on
you. This is no excuse, but nonetheless.

 There are no words that can describe how bad that I feel. If words
could describe it, they would be "ashamed", "embarrassed" and "loss of
respect for myself". I still can't believe that I acted in such a way in
front of all of my peers. Instead of hiding, I thought I'd respond and
learn a little about humility, and being humble.

> I did some searches but
> most everything I keep turning up is marketing speak.

Indeed.

> As to re-tasking some
> routers that are no longer in use, are you kidding me?  Am I the only one
> that finds it wasteful to take a perfectly good box and change it's role?

No, you are not. I've done the same thing, and I still do.

> I was looking for some best practices, not how to do it,  hence the "Best
> Practices" and not "How do I setup a metro e from scratch?"

Ok, the books and docs that I've read over the last couple of years that
I recommend highly (given that I don't know exactly what type of info
you are looking for):

http://www.ciscopress.com/bookstore/product.asp?isbn=1587050412
http://www.amazon.com/Router-Security-Strategies-Securing-Network/dp/1587053365

...and the mandatory ones:

- http://www.armware.dk/RFC/bcp/bcp38.html
- http://tools.ietf.org/html/draft-ietf-opsec-blackhole-urpf-04

Steve

ps. I'm truly sorry, Richey. I apologize to you, and everyone on this list.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090919/61ce9232/attachment.bin>

From rwest at zyedge.com  Sat Sep 19 21:15:48 2009
From: rwest at zyedge.com (Ryan West)
Date: Sat, 19 Sep 2009 21:15:48 -0400
Subject: [c-nsp] "Enhanced" download procedure - better workaround,
 for some :)
In-Reply-To: <5EB9799F396A304686962AFFF740ED0C0168362530@NOOSLEXCH001.adno.local>
References: <98424577.1493471253223622619.JavaMail.root@zmail.newpaltz.edu>
	<alpine.BSF.2.00.0909181456280.34749@murf.icantclick.org>
	<D49C1A85-BB57-42E0-8301-472E1A83A91E@puck.nether.net>
	<5EB9799F396A304686962AFFF740ED0C0168362530@NOOSLEXCH001.adno.local>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124C180EC61@zy-ex1.zyedge.local>

Stig,

I ran into a little trouble with your script at first, I was going to download now, rather than the cart and it wasn't matching the page.  I changed the included page to http://tools.cisco.com/support/downloads/go/DownloadCart.x* and now it matches for both download now and add to cart -> select Download Cart.

Thanks a lot for incorporating Bruce's javascript into your scripts, works great.

-ryan


I then chose to make a greasemonkey-script to use this info (in a somewhat similar way to what Bruce A. Locke did in his little javascript) and present it on the downloadcart-page itself.

http://userscripts.org/scripts/show/58082

/Stig
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From Stig.Johansen at atea.no  Sat Sep 19 21:24:58 2009
From: Stig.Johansen at atea.no (Stig Johansen)
Date: Sun, 20 Sep 2009 03:24:58 +0200
Subject: [c-nsp] "Enhanced" download procedure - better workaround,
 for some :)
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E140124C180EC61@zy-ex1.zyedge.local>
References: <98424577.1493471253223622619.JavaMail.root@zmail.newpaltz.edu>
	<alpine.BSF.2.00.0909181456280.34749@murf.icantclick.org>
	<D49C1A85-BB57-42E0-8301-472E1A83A91E@puck.nether.net>
	<5EB9799F396A304686962AFFF740ED0C0168362530@NOOSLEXCH001.adno.local>
	<6E21B2BDEF6E714EA0B5BA8D5D0E140124C180EC61@zy-ex1.zyedge.local>
Message-ID: <5EB9799F396A304686962AFFF740ED0C0168362531@NOOSLEXCH001.adno.local>

Ryan West wrote:
>I ran into a little trouble with your script at first, 
>I was going to download now, rather than the cart and 
>it wasn't matching the page.  I changed the included page to 
>http://tools.cisco.com/support/downloads/go/DownloadCart.x* 
>and now it matches for both download now and add to cart -> 
>select Download Cart.

I have fixed this in the script now. Thanks for the bugreport.. :)

/Stig

From mylists at battleop.com  Sat Sep 19 21:57:54 2009
From: mylists at battleop.com (Richey)
Date: Sat, 19 Sep 2009 21:57:54 -0400
Subject: [c-nsp] Metro E best practices
In-Reply-To: <4AB56E56.9020005@ibctech.ca>
References: <019401ca38d1$8269e9e0$873dbda0$@com> <4AB453C8.8040908@ibctech.ca>
	<021101ca3939$2fdf4180$8f9dc480$@com> <4AB56E56.9020005@ibctech.ca>
Message-ID: <037401ca3995$c59977c0$50cc6740$@com>

Steve,

We are all human and can tend to go off on someone especially when bad
things happen.  I've been in your shoes before and I can certainly
understand your side.  It shows you are a man of good character by posting
this publicly.  Thanks for the links, I am sure I will learn some stuff I
didn't know before.

Richey

-----Original Message-----
From: Steve Bertrand [mailto:steve at ibctech.ca] 
Sent: Saturday, September 19, 2009 7:51 PM
To: Richey
Cc: Cisco-NSP Mailing List
Subject: Re: [c-nsp] Metro E best practices

Richey, I am very sorry. My response is not typical of my normal actions.

I've had a significant tragedy happen, and I completely took it out on
you. This is no excuse, but nonetheless.

 There are no words that can describe how bad that I feel. If words
could describe it, they would be "ashamed", "embarrassed" and "loss of
respect for myself". I still can't believe that I acted in such a way in
front of all of my peers. Instead of hiding, I thought I'd respond and
learn a little about humility, and being humble.

> I did some searches but
> most everything I keep turning up is marketing speak.

Indeed.

> As to re-tasking some
> routers that are no longer in use, are you kidding me?  Am I the only one
> that finds it wasteful to take a perfectly good box and change it's role?

No, you are not. I've done the same thing, and I still do.

> I was looking for some best practices, not how to do it,  hence the "Best
> Practices" and not "How do I setup a metro e from scratch?"

Ok, the books and docs that I've read over the last couple of years that
I recommend highly (given that I don't know exactly what type of info
you are looking for):

http://www.ciscopress.com/bookstore/product.asp?isbn=1587050412
http://www.amazon.com/Router-Security-Strategies-Securing-Network/dp/1587053
365

...and the mandatory ones:

- http://www.armware.dk/RFC/bcp/bcp38.html
- http://tools.ietf.org/html/draft-ietf-opsec-blackhole-urpf-04

Steve

ps. I'm truly sorry, Richey. I apologize to you, and everyone on this list.


From sfischer1967 at gmail.com  Sun Sep 20 17:41:08 2009
From: sfischer1967 at gmail.com (Steve Fischer)
Date: Sun, 20 Sep 2009 17:41:08 -0400
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me on
	this?
Message-ID: <027701ca3a3b$1164ca60$342e5f20$@com>

Last Thursday evening, at around midnight, in the course of my organizations
network maintenance, we had not one but two of our core 6500 switches go
into ROMMON (after being rebooted with new code, and being operational for
approximately 45 minutes)at the same time and for no apparent reason.
Attempts to reboot the devices were in vain, and attempts to roll-back also
appeared to be in vain, so I called the Cisco TAC and opened a P1 case.
Immediately, the call was routed over to India.  I was in a loud data
center, and the engineers accent was very thick, to the point I could not
hear him over the background noise, much less understand him.  Other than
asking for a webex session - made impossible by the fact that the network
core is down, he offers nothing in the way of assistance.

 

I asked to have the case transferred to a native-English speaking engineer.
Call transferred to Indian engineer #2, and the communications issues
persist.  I have two core switches down, and am becoming more than a little
concerned.  Same result - engineer really offers nothing in the way of
assistance, and I again, request the call to be transferred to a
native-English speaking engineer.  Enter Indian engineer #3.  Now let me
state here for the record that I am in no way questioning the competence of
the three gentlemen I spoke to, nor do I have any xenophobic tendencies, but
I would like to make a few points here:

 

1.       If I cannot understand the support engineer, it will be difficult
for him to assist me, regardless of his skill level.

2.       Having a native-English speaking engineer available would have been
at this time very disarming, and calming in the midst of for what was for me
a crisis.  In the medical field, they call it bed-side manner, which would
have been of immense value given the crisis I was facing.

3.       My organization spends well over $100K annually in Cisco
maintenance.

 

Case transferred to Indian engineer #4.  Now, while this was occurring, I
called Cisco's TAC and asked the case be re-queued to an engineer in North
America.  I was told that there were no support engineers on duty in North
America.  Now, I'm getting upset, and more than just a little. Also, in the
meantime, it was suggested that I remove one of the CompactFlash cards from
one of the 6500's that was still working (we have 4 total), and try to boot
from the IOS image on it.  Upon ejecting the Flash card, that 6500 too, went
immediately into ROMMON.  So, now, we have 3 of 4 core switches down.  The
entire data center is down, and are one step away from the phone system
going down as well - which indeed did happen.  As we now have all four cores
down, the options of rebooting them with the old code. One by one, through
all four cores, they are rolled back, and finally the network comes up.  Let
me say the fourth engineer suggested this, by prior to that, I had concluded
this was going to be the best course of action.

 

Now, back up two weeks.  I had a Cisco Works issue at around 3:00PM EST, and
open a case for it.  The call is transferred to.wait for it.India.  So, it
doesn't appear that the time of an issue completely influences to what Cisco
support center a call is routed.  As a matter of fact, the support engineer
for that particular call informed me it was 2:00AM where he was.  

 

This leads me to several questions that perhaps someone from Cisco
monitoring this forum could answer.

 

1.       Given the stature of the 6500 platform within Cisco's product line,
and given the severity of the issue I was experiencing, is there no Cisco
Support Center in North America staffed 24X7X365 to deal with such issues?

2.       Was the only option available to me a webex session?  It seemed
strange that the engineer would even ask for that, given that this was
reported as a network down emergency.

3.       Upon asking the call be transferred to a native English speaking
engineer, why was the call routed to 3 more Indian engineers? Rather than
informing me that no native English-speaking engineers were available, why
did I have to request this three more times?  I find it INCREDIBLE that an
organization of Cisco's size could not find a single native English-speaking
engineer to assist me in this crisis concerning their flagship product.

4.       Does Cisco as a company understand the value of being disarming to
a stressed-out client in the midst of a crisis, and how much providing a
support engineer who can clearly and effectively communicate with the
customer?

 

If I were to grade Cisco on this support call, and to my knowledge, this was
the first network down call I've opened since I've been with this
organization, I'd give Cisco an F.no, an F-.  This was an epic-fail for
Cisco, to the point that my organization is considering dumping their
support all together, and going with a third party.  There is just no way I
should have been bounced to four Indian engineers when after the first one,
and the second one, I calmly explained the rationale behind requesting a
native English-speaking engineer.  

 

What can Cisco do to make this right?

 

1.       A written letter of apology.  I don't blame the engineers for this
- they are likely highly competent support engineers.  Cisco failed to
provide an engineer who could communicate with me clearly and concisely. 

2.       Provide an additional one year of maintenance coverage on all four
of our 6500's free of charge, as that pales by comparison to the amount of
money lost by my company for the two hours our network was down, and I was
unable to reach an engineer who could effectively communicate with me.

3.       Staff a support center in North America 24X7X365 geared to deal
with exactly the issue I encountered.  A P1 case should be treated
differently than a P3 case, and this case wasn't, at least not from my
perspective.

4.       When it became clear that the communications issues that existed
between the support engineer and myself precluded progress being made to
resolve the issue, and I requested the case be escalated, escalate the case.
I DO blame the engineer for that - not escalating the case when requested to
do so.    

5.       Stop making the first course of action being requesting a webex.
There will be scenarios where that won't be possible, as was the case
Thursday evening.  Engineer 1 seemed to give up when webex wasn't an option.

 

I am interested in any and all feedback from the community on this.  If
there is someone within Cisco (other than my salesperson, who's heard this
before from me.on more than one occasion) who I can send this to, and can
respond to it, it would also be appreciated.


From william.mccall at gmail.com  Sun Sep 20 18:33:48 2009
From: william.mccall at gmail.com (William McCall)
Date: Sun, 20 Sep 2009 17:33:48 -0500
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
	on this?
In-Reply-To: <027701ca3a3b$1164ca60$342e5f20$@com>
References: <027701ca3a3b$1164ca60$342e5f20$@com>
Message-ID: <f9a8f300909201533h1698580fq293e5f5c9ffd6edd@mail.gmail.com>

I would advise you to make sure to fill out the eval among other
things. This is a situation where I'd put all 1's. Make sure to put in
the comments too.

Those evals (known as BINGOs internally) are a big deal and may help
you with getting some motion.

Of course, follow up with your AM and see what they can do.

On 9/20/09, Steve Fischer <sfischer1967 at gmail.com> wrote:
> Last Thursday evening, at around midnight, in the course of my organizations
> network maintenance, we had not one but two of our core 6500 switches go
> into ROMMON (after being rebooted with new code, and being operational for
> approximately 45 minutes)at the same time and for no apparent reason.
> Attempts to reboot the devices were in vain, and attempts to roll-back also
> appeared to be in vain, so I called the Cisco TAC and opened a P1 case.
> Immediately, the call was routed over to India.  I was in a loud data
> center, and the engineers accent was very thick, to the point I could not
> hear him over the background noise, much less understand him.  Other than
> asking for a webex session - made impossible by the fact that the network
> core is down, he offers nothing in the way of assistance.
>
>
>
> I asked to have the case transferred to a native-English speaking engineer.
> Call transferred to Indian engineer #2, and the communications issues
> persist.  I have two core switches down, and am becoming more than a little
> concerned.  Same result - engineer really offers nothing in the way of
> assistance, and I again, request the call to be transferred to a
> native-English speaking engineer.  Enter Indian engineer #3.  Now let me
> state here for the record that I am in no way questioning the competence of
> the three gentlemen I spoke to, nor do I have any xenophobic tendencies, but
> I would like to make a few points here:
>
>
>
> 1.       If I cannot understand the support engineer, it will be difficult
> for him to assist me, regardless of his skill level.
>
> 2.       Having a native-English speaking engineer available would have been
> at this time very disarming, and calming in the midst of for what was for me
> a crisis.  In the medical field, they call it bed-side manner, which would
> have been of immense value given the crisis I was facing.
>
> 3.       My organization spends well over $100K annually in Cisco
> maintenance.
>
>
>
> Case transferred to Indian engineer #4.  Now, while this was occurring, I
> called Cisco's TAC and asked the case be re-queued to an engineer in North
> America.  I was told that there were no support engineers on duty in North
> America.  Now, I'm getting upset, and more than just a little. Also, in the
> meantime, it was suggested that I remove one of the CompactFlash cards from
> one of the 6500's that was still working (we have 4 total), and try to boot
> from the IOS image on it.  Upon ejecting the Flash card, that 6500 too, went
> immediately into ROMMON.  So, now, we have 3 of 4 core switches down.  The
> entire data center is down, and are one step away from the phone system
> going down as well - which indeed did happen.  As we now have all four cores
> down, the options of rebooting them with the old code. One by one, through
> all four cores, they are rolled back, and finally the network comes up.  Let
> me say the fourth engineer suggested this, by prior to that, I had concluded
> this was going to be the best course of action.
>
>
>
> Now, back up two weeks.  I had a Cisco Works issue at around 3:00PM EST, and
> open a case for it.  The call is transferred to.wait for it.India.  So, it
> doesn't appear that the time of an issue completely influences to what Cisco
> support center a call is routed.  As a matter of fact, the support engineer
> for that particular call informed me it was 2:00AM where he was.
>
>
>
> This leads me to several questions that perhaps someone from Cisco
> monitoring this forum could answer.
>
>
>
> 1.       Given the stature of the 6500 platform within Cisco's product line,
> and given the severity of the issue I was experiencing, is there no Cisco
> Support Center in North America staffed 24X7X365 to deal with such issues?
>
> 2.       Was the only option available to me a webex session?  It seemed
> strange that the engineer would even ask for that, given that this was
> reported as a network down emergency.
>
> 3.       Upon asking the call be transferred to a native English speaking
> engineer, why was the call routed to 3 more Indian engineers? Rather than
> informing me that no native English-speaking engineers were available, why
> did I have to request this three more times?  I find it INCREDIBLE that an
> organization of Cisco's size could not find a single native English-speaking
> engineer to assist me in this crisis concerning their flagship product.
>
> 4.       Does Cisco as a company understand the value of being disarming to
> a stressed-out client in the midst of a crisis, and how much providing a
> support engineer who can clearly and effectively communicate with the
> customer?
>
>
>
> If I were to grade Cisco on this support call, and to my knowledge, this was
> the first network down call I've opened since I've been with this
> organization, I'd give Cisco an F.no, an F-.  This was an epic-fail for
> Cisco, to the point that my organization is considering dumping their
> support all together, and going with a third party.  There is just no way I
> should have been bounced to four Indian engineers when after the first one,
> and the second one, I calmly explained the rationale behind requesting a
> native English-speaking engineer.
>
>
>
> What can Cisco do to make this right?
>
>
>
> 1.       A written letter of apology.  I don't blame the engineers for this
> - they are likely highly competent support engineers.  Cisco failed to
> provide an engineer who could communicate with me clearly and concisely.
>
> 2.       Provide an additional one year of maintenance coverage on all four
> of our 6500's free of charge, as that pales by comparison to the amount of
> money lost by my company for the two hours our network was down, and I was
> unable to reach an engineer who could effectively communicate with me.
>
> 3.       Staff a support center in North America 24X7X365 geared to deal
> with exactly the issue I encountered.  A P1 case should be treated
> differently than a P3 case, and this case wasn't, at least not from my
> perspective.
>
> 4.       When it became clear that the communications issues that existed
> between the support engineer and myself precluded progress being made to
> resolve the issue, and I requested the case be escalated, escalate the case.
> I DO blame the engineer for that - not escalating the case when requested to
> do so.
>
> 5.       Stop making the first course of action being requesting a webex.
> There will be scenarios where that won't be possible, as was the case
> Thursday evening.  Engineer 1 seemed to give up when webex wasn't an option.
>
>
>
> I am interested in any and all feedback from the community on this.  If
> there is someone within Cisco (other than my salesperson, who's heard this
> before from me.on more than one occasion) who I can send this to, and can
> respond to it, it would also be appreciated.
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

-- 
Sent from my mobile device

William McCall, CCIE #25044

From jeff-kell at utc.edu  Sun Sep 20 22:54:01 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Sun, 20 Sep 2009 22:54:01 -0400
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
 on	this?
In-Reply-To: <027701ca3a3b$1164ca60$342e5f20$@com>
References: <027701ca3a3b$1164ca60$342e5f20$@com>
Message-ID: <4AB6EAC9.6070101@utc.edu>

Front-line TAC has gotten "incomprehensibly" bad.  The most recent case 
came back with info request (this is a direct quote):

> To help isolate the issue, *please answer the following questions *
>
> **1. When did you noticed this issue?
>
> 2. Did you perform any  IOS upgrade recently?
>
> 3. If yes, when did you upgraded it and is the problem started 
> occurring after that  ?
>
> 4. Are we facing the same issue with all the ports ?
>
> 5. Are the devices connected to these ports are running  fine ?
>
>  
>
> Please send me the output of the "show tech".
>

Please.

Jeff




From aaron at wsc.ma.edu  Sun Sep 20 23:29:16 2009
From: aaron at wsc.ma.edu (Childs, Aaron)
Date: Sun, 20 Sep 2009 23:29:16 -0400
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
 on	this?
In-Reply-To: <027701ca3a3b$1164ca60$342e5f20$@com>
References: <027701ca3a3b$1164ca60$342e5f20$@com>
Message-ID: <3760B7E1B344364AA0384B231FE7BA691264C82398@ex-be1.ads.wsc.ma.edu>

I gave up on calling TAC around 5 years ago.  All of my TAC cases are handled via e-mail (yea, I know it wasn't an option in your case) but I too have gotten sick of trying to understand their engineers.  I agree with William's comment about the evaluation.
-----------
Aaron Childs
Assistant Director, Networking
Westfield State College
http://www.wsc.ma.edu/it/
________________________________________
From: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net] On Behalf Of Steve Fischer [sfischer1967 at gmail.com]
Sent: Sunday, September 20, 2009 5:41 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me on      this?

Last Thursday evening, at around midnight, in the course of my organizations
network maintenance, we had not one but two of our core 6500 switches go
into ROMMON (after being rebooted with new code, and being operational for
approximately 45 minutes)at the same time and for no apparent reason.
Attempts to reboot the devices were in vain, and attempts to roll-back also
appeared to be in vain, so I called the Cisco TAC and opened a P1 case.
Immediately, the call was routed over to India.  I was in a loud data
center, and the engineers accent was very thick, to the point I could not
hear him over the background noise, much less understand him.  Other than
asking for a webex session - made impossible by the fact that the network
core is down, he offers nothing in the way of assistance.



I asked to have the case transferred to a native-English speaking engineer.
Call transferred to Indian engineer #2, and the communications issues
persist.  I have two core switches down, and am becoming more than a little
concerned.  Same result - engineer really offers nothing in the way of
assistance, and I again, request the call to be transferred to a
native-English speaking engineer.  Enter Indian engineer #3.  Now let me
state here for the record that I am in no way questioning the competence of
the three gentlemen I spoke to, nor do I have any xenophobic tendencies, but
I would like to make a few points here:



1.       If I cannot understand the support engineer, it will be difficult
for him to assist me, regardless of his skill level.

2.       Having a native-English speaking engineer available would have been
at this time very disarming, and calming in the midst of for what was for me
a crisis.  In the medical field, they call it bed-side manner, which would
have been of immense value given the crisis I was facing.

3.       My organization spends well over $100K annually in Cisco
maintenance.



Case transferred to Indian engineer #4.  Now, while this was occurring, I
called Cisco's TAC and asked the case be re-queued to an engineer in North
America.  I was told that there were no support engineers on duty in North
America.  Now, I'm getting upset, and more than just a little. Also, in the
meantime, it was suggested that I remove one of the CompactFlash cards from
one of the 6500's that was still working (we have 4 total), and try to boot
from the IOS image on it.  Upon ejecting the Flash card, that 6500 too, went
immediately into ROMMON.  So, now, we have 3 of 4 core switches down.  The
entire data center is down, and are one step away from the phone system
going down as well - which indeed did happen.  As we now have all four cores
down, the options of rebooting them with the old code. One by one, through
all four cores, they are rolled back, and finally the network comes up.  Let
me say the fourth engineer suggested this, by prior to that, I had concluded
this was going to be the best course of action.



Now, back up two weeks.  I had a Cisco Works issue at around 3:00PM EST, and
open a case for it.  The call is transferred to.wait for it.India.  So, it
doesn't appear that the time of an issue completely influences to what Cisco
support center a call is routed.  As a matter of fact, the support engineer
for that particular call informed me it was 2:00AM where he was.



This leads me to several questions that perhaps someone from Cisco
monitoring this forum could answer.



1.       Given the stature of the 6500 platform within Cisco's product line,
and given the severity of the issue I was experiencing, is there no Cisco
Support Center in North America staffed 24X7X365 to deal with such issues?

2.       Was the only option available to me a webex session?  It seemed
strange that the engineer would even ask for that, given that this was
reported as a network down emergency.

3.       Upon asking the call be transferred to a native English speaking
engineer, why was the call routed to 3 more Indian engineers? Rather than
informing me that no native English-speaking engineers were available, why
did I have to request this three more times?  I find it INCREDIBLE that an
organization of Cisco's size could not find a single native English-speaking
engineer to assist me in this crisis concerning their flagship product.

4.       Does Cisco as a company understand the value of being disarming to
a stressed-out client in the midst of a crisis, and how much providing a
support engineer who can clearly and effectively communicate with the
customer?



If I were to grade Cisco on this support call, and to my knowledge, this was
the first network down call I've opened since I've been with this
organization, I'd give Cisco an F.no, an F-.  This was an epic-fail for
Cisco, to the point that my organization is considering dumping their
support all together, and going with a third party.  There is just no way I
should have been bounced to four Indian engineers when after the first one,
and the second one, I calmly explained the rationale behind requesting a
native English-speaking engineer.



What can Cisco do to make this right?



1.       A written letter of apology.  I don't blame the engineers for this
- they are likely highly competent support engineers.  Cisco failed to
provide an engineer who could communicate with me clearly and concisely.

2.       Provide an additional one year of maintenance coverage on all four
of our 6500's free of charge, as that pales by comparison to the amount of
money lost by my company for the two hours our network was down, and I was
unable to reach an engineer who could effectively communicate with me.

3.       Staff a support center in North America 24X7X365 geared to deal
with exactly the issue I encountered.  A P1 case should be treated
differently than a P3 case, and this case wasn't, at least not from my
perspective.

4.       When it became clear that the communications issues that existed
between the support engineer and myself precluded progress being made to
resolve the issue, and I requested the case be escalated, escalate the case.
I DO blame the engineer for that - not escalating the case when requested to
do so.

5.       Stop making the first course of action being requesting a webex.
There will be scenarios where that won't be possible, as was the case
Thursday evening.  Engineer 1 seemed to give up when webex wasn't an option.



I am interested in any and all feedback from the community on this.  If
there is someone within Cisco (other than my salesperson, who's heard this
before from me.on more than one occasion) who I can send this to, and can
respond to it, it would also be appreciated.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From sfischer1967 at gmail.com  Mon Sep 21 00:26:43 2009
From: sfischer1967 at gmail.com (Steve Fischer)
Date: Mon, 21 Sep 2009 00:26:43 -0400
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
	onthis?
In-Reply-To: <368128042-1253485053-cardhu_decombobulator_blackberry.rim.net-1655968457-@bda277.bisx.prod.on.blackberry>
References: <027701ca3a3b$1164ca60$342e5f20$@com>
	<368128042-1253485053-cardhu_decombobulator_blackberry.rim.net-1655968457-@bda277.bisx.prod.on.blackberry>
Message-ID: <028001ca3a73$ba076fa0$2e164ee0$@com>

Richard - 

This would be more acceptable (at least to me), were this an issue with a
3560 switch, or a 2800 series router, but this was 2 core switches of their
flagship product, the 6500.  Enterprise data centers throughout the US. Like
the one at my organization, rely heavily on this product, and it should be
supported as such.  I understand the problem, but given the criticality of
these devices as they relate to the core infrastructure of so many
organizations, transferring the call to India is not an acceptable way of
dealing with it.  

This is an embarrassment for an organization of this size to provide a
substandard level of support, when the support is being paid for, and at the
level it is being paid for.  

If I had waited a few hours...I would have been fired, and rightfully so.

What I also feel really bad about is this must have been frustrating for the
four Indian engineers as well.  Cisco put them in a position where they
really couldn't be successful in helping me, due to something that isn't
their fault.  It wouldn't be fair to transfer their P1 network emergency
calls to me, either.  There is a communication barrier that makes conversing
difficult.

I view the maintenance contracts like I view car insurance - I'm paying for
something I hope I never need.  But, a situation arose Thursday evening
where I did need it, and the service wasn't available in a manner that could
assist me.  At a minimum, a refund or credit should be forthcoming.

To be fair to Cisco as a whole, my local account team is picking this case
up and running with it.  But, that doesn't absolve the TAC of malfeasance. 

-----Original Message-----
From: rgolodner at infratection.com [mailto:rgolodner at infratection.com] 
Sent: Sunday, September 20, 2009 6:17 PM
To: Steve Fischer
Subject: Re: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
onthis?

I have had the same problem. Basically TAC follows the sun. If you had
waited a few hours you would have had an Irish tech. It is a problem and not
just with Cisco
       Richard
Sent via BlackBerry from T-Mobile

-----Original Message-----
From: "Steve Fischer" <sfischer1967 at gmail.com>

Date: Sun, 20 Sep 2009 17:41:08 
To: <cisco-nsp at puck.nether.net>
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me on
	this?


Last Thursday evening, at around midnight, in the course of my organizations
network maintenance, we had not one but two of our core 6500 switches go
into ROMMON (after being rebooted with new code, and being operational for
approximately 45 minutes)at the same time and for no apparent reason.
Attempts to reboot the devices were in vain, and attempts to roll-back also
appeared to be in vain, so I called the Cisco TAC and opened a P1 case.
Immediately, the call was routed over to India.  I was in a loud data
center, and the engineers accent was very thick, to the point I could not
hear him over the background noise, much less understand him.  Other than
asking for a webex session - made impossible by the fact that the network
core is down, he offers nothing in the way of assistance.

 

I asked to have the case transferred to a native-English speaking engineer.
Call transferred to Indian engineer #2, and the communications issues
persist.  I have two core switches down, and am becoming more than a little
concerned.  Same result - engineer really offers nothing in the way of
assistance, and I again, request the call to be transferred to a
native-English speaking engineer.  Enter Indian engineer #3.  Now let me
state here for the record that I am in no way questioning the competence of
the three gentlemen I spoke to, nor do I have any xenophobic tendencies, but
I would like to make a few points here:

 

1.       If I cannot understand the support engineer, it will be difficult
for him to assist me, regardless of his skill level.

2.       Having a native-English speaking engineer available would have been
at this time very disarming, and calming in the midst of for what was for me
a crisis.  In the medical field, they call it bed-side manner, which would
have been of immense value given the crisis I was facing.

3.       My organization spends well over $100K annually in Cisco
maintenance.

 

Case transferred to Indian engineer #4.  Now, while this was occurring, I
called Cisco's TAC and asked the case be re-queued to an engineer in North
America.  I was told that there were no support engineers on duty in North
America.  Now, I'm getting upset, and more than just a little. Also, in the
meantime, it was suggested that I remove one of the CompactFlash cards from
one of the 6500's that was still working (we have 4 total), and try to boot
from the IOS image on it.  Upon ejecting the Flash card, that 6500 too, went
immediately into ROMMON.  So, now, we have 3 of 4 core switches down.  The
entire data center is down, and are one step away from the phone system
going down as well - which indeed did happen.  As we now have all four cores
down, the options of rebooting them with the old code. One by one, through
all four cores, they are rolled back, and finally the network comes up.  Let
me say the fourth engineer suggested this, by prior to that, I had concluded
this was going to be the best course of action.

 

Now, back up two weeks.  I had a Cisco Works issue at around 3:00PM EST, and
open a case for it.  The call is transferred to.wait for it.India.  So, it
doesn't appear that the time of an issue completely influences to what Cisco
support center a call is routed.  As a matter of fact, the support engineer
for that particular call informed me it was 2:00AM where he was.  

 

This leads me to several questions that perhaps someone from Cisco
monitoring this forum could answer.

 

1.       Given the stature of the 6500 platform within Cisco's product line,
and given the severity of the issue I was experiencing, is there no Cisco
Support Center in North America staffed 24X7X365 to deal with such issues?

2.       Was the only option available to me a webex session?  It seemed
strange that the engineer would even ask for that, given that this was
reported as a network down emergency.

3.       Upon asking the call be transferred to a native English speaking
engineer, why was the call routed to 3 more Indian engineers? Rather than
informing me that no native English-speaking engineers were available, why
did I have to request this three more times?  I find it INCREDIBLE that an
organization of Cisco's size could not find a single native English-speaking
engineer to assist me in this crisis concerning their flagship product.

4.       Does Cisco as a company understand the value of being disarming to
a stressed-out client in the midst of a crisis, and how much providing a
support engineer who can clearly and effectively communicate with the
customer?

 

If I were to grade Cisco on this support call, and to my knowledge, this was
the first network down call I've opened since I've been with this
organization, I'd give Cisco an F.no, an F-.  This was an epic-fail for
Cisco, to the point that my organization is considering dumping their
support all together, and going with a third party.  There is just no way I
should have been bounced to four Indian engineers when after the first one,
and the second one, I calmly explained the rationale behind requesting a
native English-speaking engineer.  

 

What can Cisco do to make this right?

 

1.       A written letter of apology.  I don't blame the engineers for this
- they are likely highly competent support engineers.  Cisco failed to
provide an engineer who could communicate with me clearly and concisely. 

2.       Provide an additional one year of maintenance coverage on all four
of our 6500's free of charge, as that pales by comparison to the amount of
money lost by my company for the two hours our network was down, and I was
unable to reach an engineer who could effectively communicate with me.

3.       Staff a support center in North America 24X7X365 geared to deal
with exactly the issue I encountered.  A P1 case should be treated
differently than a P3 case, and this case wasn't, at least not from my
perspective.

4.       When it became clear that the communications issues that existed
between the support engineer and myself precluded progress being made to
resolve the issue, and I requested the case be escalated, escalate the case.
I DO blame the engineer for that - not escalating the case when requested to
do so.    

5.       Stop making the first course of action being requesting a webex.
There will be scenarios where that won't be possible, as was the case
Thursday evening.  Engineer 1 seemed to give up when webex wasn't an option.

 

I am interested in any and all feedback from the community on this.  If
there is someone within Cisco (other than my salesperson, who's heard this
before from me.on more than one occasion) who I can send this to, and can
respond to it, it would also be appreciated.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



From streiner at cluebyfour.org  Mon Sep 21 00:58:05 2009
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Mon, 21 Sep 2009 00:58:05 -0400 (EDT)
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
 on this?
In-Reply-To: <4AB6EAC9.6070101@utc.edu>
References: <027701ca3a3b$1164ca60$342e5f20$@com> <4AB6EAC9.6070101@utc.edu>
Message-ID: <Pine.LNX.4.64.0909210045430.6983@whammy.cluebyfour.org>

On Sun, 20 Sep 2009, Jeff Kell wrote:

> Front-line TAC has gotten "incomprehensibly" bad.  The most recent case came 
> back with info request (this is a direct quote):

I've run into this in the past with different vendors, even on occasions 
when the most frequently needed information ("show tech", "request 
tech-support", etc...) is attached to the support case before it gets 
assigned to an engineer.  A response like the one that was previously 
posted indicates that the engineer who handled the case failed to look at 
those attachments, wasting time and effort on both sides.  I think a 
language barrier has factored into this to some degree.  When issues like 
this come up, I make sure my account team for $VENDOR knows about it and 
that has helped.

jms

From hank at efes.iucc.ac.il  Mon Sep 21 01:35:38 2009
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Mon, 21 Sep 2009 08:35:38 +0300
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
 on	this?
In-Reply-To: <4AB6EAC9.6070101@utc.edu>
References: <027701ca3a3b$1164ca60$342e5f20$@com>
	<027701ca3a3b$1164ca60$342e5f20$@com>
Message-ID: <5.1.0.14.2.20090921082845.055a0ec0@efes.iucc.ac.il>

At 22:54 20/09/2009 -0400, Jeff Kell wrote:
>Front-line TAC has gotten "incomprehensibly" bad.  The most recent case 
>came back with info request (this is a direct quote):
>
>>To help isolate the issue, *please answer the following questions *
>>
>>**1. When did you noticed this issue?
>>
>>2. Did you perform any  IOS upgrade recently?
>>
>>3. If yes, when did you upgraded it and is the problem started occurring 
>>after that  ?
>>
>>4. Are we facing the same issue with all the ports ?
>>
>>5. Are the devices connected to these ports are running  fine ?

And this seems strange to you, why? :-)

We dropped TAC last year and haven't looked back.

Next we drop Cisco.

-Hank


>>
>>
>>Please send me the output of the "show tech".
>
>Please.
>
>Jeff
>
>
>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/


From hank at efes.iucc.ac.il  Mon Sep 21 01:42:36 2009
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Mon, 21 Sep 2009 08:42:36 +0300
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
 on this?
In-Reply-To: <027701ca3a3b$1164ca60$342e5f20$@com>
Message-ID: <5.1.0.14.2.20090921083807.055e4400@efes.iucc.ac.il>

At 17:41 20/09/2009 -0400, Steve Fischer wrote:


>I am interested in any and all feedback from the community on this.  If
>there is someone within Cisco (other than my salesperson, who's heard this
>before from me.on more than one occasion) who I can send this to, and can
>respond to it, it would also be appreciated.

I feel your pain.

Cisco lives by their stock value:
http://finance.yahoo.com/echarts?s=CSCO#chart12:symbol=csco;range=2y;indicator=volume;charttype=line;crosshair=on;ohlcvalues=0;logscale=on;source=undefined

Cisco has been shedding staff all year:
http://www.computerweekly.com/Articles/2009/02/05/234641/cisco-to-lay-off-up-to-6700-staff-as-outlook-deteriorates.htm
http://www.networkworld.com/news/2009/071609-cisco-layoffs.html

Might very well be the people who could help you are among those that were 
laid off.

Don't expect anything better within the next 2 years.

Regards,
Hank


From andy.saykao at staff.netspace.net.au  Mon Sep 21 01:44:12 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Mon, 21 Sep 2009 15:44:12 +1000
Subject: [c-nsp] Router logs going to dmesg
Message-ID: <56F211C5E3F24F47B103EA1B253822BE044AAC3C@vic-cr-ex1.staff.netspace.net.au>

Hi All,
 
I'm trying to send cisco logs to a syslog server running Solaris 9. It's
logging fine except that I'm seeing some logs showing up in dmesg. 
 
Example of a dmesg outout:
 
Sep 21 13:44:16 [172.16.9.18.224.173] 3297: Sep 21 13:44:15.981 AEST:
%LINK-3-UPDOWN: Interface GigabitEthernet0/45, changed state to down
Sep 21 13:44:21 [172.16.9.18.224.173] 3298: Sep 21 13:44:20.956 AEST:
%LINK-3-UPDOWN: Interface GigabitEthernet0/45, changed state to up
Sep 21 13:48:38 agr1-cr-loopback-0.x.x.x 315047: Sep 21 13:48:37.756
AEST: %SNMP-3-AUTHFAIL: Authentication failure for SNMP req from host
83.143.128.1

I've tried changing the facility to local0.info on the cisco devices but
still the same thing is happening. Is there a particular facility I
should be using so the logs don't appear in dmesg???
 
This was the only thing I could find on goggle about my problem but no
real solution.
 
http://www.velocityreviews.com/forums/t34315-which-facility-is-best-for-
logging-to-linux-syslog.html
 
 
This is my /etc/syslog.conf file.
 
# Log cisco routers
local0.info                                     /var/log/cisco.log

 
And my config on the routers.
 
logging facility local0
logging source-interface Loopback0
logging 210.15.210.x

Thanks.
 
Andy

This email and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed. 
Please notify the sender immediately by email if you have received this 
email by mistake and delete this email from your system. 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 organisation. 
Finally, the recipient should check this email and any attachments for 
the presence of viruses. The organisation accepts no liability for any 
damage caused by any virus transmitted by this email.


From rgolodner at infratection.com  Mon Sep 21 01:50:56 2009
From: rgolodner at infratection.com (Richard Golodner)
Date: Mon, 21 Sep 2009 00:50:56 -0500
Subject: [c-nsp] can someone from Cisco enlighten Steve and the rest of us?
In-Reply-To: <028001ca3a73$ba076fa0$2e164ee0$@com>
References: <027701ca3a3b$1164ca60$342e5f20$@com>
	<368128042-1253485053-cardhu_decombobulator_blackberry.rim.net-1655968457-@bda277.bisx.prod.on.blackberry>
	<028001ca3a73$ba076fa0$2e164ee0$@com>
Message-ID: <1253512256.11498.80.camel@Andromeda>

On Mon, 2009-09-21 at 00:26 -0400, Steve Fischer wrote:
> This would be more acceptable (at least to me), were this an issue
> with a
> 3560 switch, or a 2800 series router, but this was 2 core switches of
> their
> flagship product, the 6500.  Enterprise data centers throughout the
> US. Like
> the one at my organization, rely heavily on this product, and it
> should be
> supported as such.  I understand the problem, but given the
> criticality of
> these devices as they relate to the core infrastructure of so many
> organizations, transferring the call to India is not an acceptable way
> of
> dealing with it. 
	Steve, I agree completely. I see some of the C-NSP posters don't even
deal with TAC other than by email. 
	It is a shame when a company asks the price they do for not only the
hardware and software of the device, but the paid support should be
useful and effective.
	I think it might be time that Cisco reexamine their outsourcing of
support for mission critical hardware. I have spoken to some very bright
people not only at Cisco, but Watchguard and a few other vendors whose
support is India based. These are smart men and women, we just need to
be able to understand what is being said on the other end of the phone,
which is often complicated by the fact that I am on speakerphone.
	Cisco should be made aware of this in every way possible as long as it
is constructive for the community. 
	I applaud your patience and fortitude and I also know I would probably
have not handled the situation as coolly as you did. Sorry you had to
deal with this. 
	Hopefully, as a result of your experience Cisco will work to improve
how these network down emergencies are handled.
	Sincerely, Richard


From sethm at rollernet.us  Mon Sep 21 02:16:07 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Sun, 20 Sep 2009 23:16:07 -0700
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
 on	this?
In-Reply-To: <5.1.0.14.2.20090921082845.055a0ec0@efes.iucc.ac.il>
References: <027701ca3a3b$1164ca60$342e5f20$@com>	<027701ca3a3b$1164ca60$342e5f20$@com>
	<5.1.0.14.2.20090921082845.055a0ec0@efes.iucc.ac.il>
Message-ID: <4AB71A27.1070700@rollernet.us>

Hank Nussbacher wrote:
> At 22:54 20/09/2009 -0400, Jeff Kell wrote:
>> Front-line TAC has gotten "incomprehensibly" bad.  The most recent
>> case came back with info request (this is a direct quote):
>>
>>> To help isolate the issue, *please answer the following questions *
>>>
>>> **1. When did you noticed this issue?
>>>
>>> 2. Did you perform any  IOS upgrade recently?
>>>
>>> 3. If yes, when did you upgraded it and is the problem started
>>> occurring after that  ?
>>>
>>> 4. Are we facing the same issue with all the ports ?
>>>
>>> 5. Are the devices connected to these ports are running  fine ?
> 
> And this seems strange to you, why? :-)
> 
> We dropped TAC last year and haven't looked back.
> 
> Next we drop Cisco.
> 

Drop Cisco for who? I have been under the impression they're all the
same. Likewise, I don't pay for super-TAC support either. I've found
that between docs and this list one get better support than TAC can
offer (software bugs that need fixing aside).

~Seth

From gert at greenie.muc.de  Mon Sep 21 03:00:57 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 21 Sep 2009 09:00:57 +0200
Subject: [c-nsp] Cisco Security Advisory: TCP State Manipulation Denial
	ofService Vulnerabilities in Multiple Cisco Products
In-Reply-To: <2716.29557.qm@web1202.biz.mail.gq1.yahoo.com>
References: <373558.22022.qm@web1210.biz.mail.gq1.yahoo.com>
	<CD0195AB-DF6F-4B41-83BD-0E6F5F0BADF9@puck.nether.net>
	<20090914143623.GE1508@greenie.muc.de>
	<20090914163011.GC25690@lboro.ac.uk>
	<20090916080639.GX1508@greenie.muc.de>
	<0E0ADFB3-3D29-4857-B6B4-92E8698B026E@hughes.com.au>
	<alpine.WNT.2.00.0909171006020.3984@pckoug1.intranet.gr>
	<412409.56453.qm@web1206.biz.mail.gq1.yahoo.com>
	<20090918210430.GY1508@greenie.muc.de>
	<2716.29557.qm@web1202.biz.mail.gq1.yahoo.com>
Message-ID: <20090921070057.GI1508@greenie.muc.de>

Hi,

On Fri, Sep 18, 2009 at 08:52:32PM -0700, Kevin Graham wrote:
> Sorry, the thought of being able to plan forward-looking purchases and
> technology migrations this beautifully makes me tingly... _These_ 
> would be the moves of a dominant market leader with a rich innovative
> history. 

Full ACK...

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090921/3db7f5b5/attachment.bin>

From zivl at gilat.net  Mon Sep 21 03:10:38 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Mon, 21 Sep 2009 10:10:38 +0300
Subject: [c-nsp] Need help troubleshooting CRC errors
In-Reply-To: <20090919162606.GE1508@greenie.muc.de>
References: <4AB211D9.9E6F.00B8.0@dps.k12.oh.us>
	<20090919162606.GE1508@greenie.muc.de>
Message-ID: <EC993E87D960A541A66BF21D62AA42A623015120BB@exch2k7.gilat.local>

I've seen similar situations where a shaping fine tuning in the carrier equipment's settings solved the CRC errors.
All the ATM VP/VC related equipment in the circuit should be shaped properly, depending on what type of service you get, CBR, VBR, etc.
Either too high or too low values could cause cells drops thus rising the CRC errors. A 20% overhead needs to be taken in count for ATM to non-ATM conversions in the circuit
HTH
Ziv


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Gert Doering
Sent: Saturday, September 19, 2009 7:26 PM
To: Steven Pfister
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Need help troubleshooting CRC errors

Hi,

On Thu, Sep 17, 2009 at 10:39:21AM -0400, Steven Pfister wrote:
> that pretty much every one of them is showing what I think is a rather 
> high receive error count on the 3640 end of the OC3 connection, and it 
> all seems to be CRC errors. Not much of any errors are showing up on 
> the 8510 end of the OC3 connection. For example, one site yesterday 
> late afternoon showed 63, 763 receive errors for the day. Several 
> others were in the 20Ks. I'm not really certain what the cause might 
> be, or where to start. Can anyone help?

Is there a carrier network in between?  In our cases, whenever we saw ATM CRC errors, it was due to dropped cells in the carrier network (overloaded).  If the receiving router cannot reassemble a packet due to missing cells -> CRC error.

If the STM-1 is "direct", no carrier ATM gear in between (just SDH/SONET)
gear, it be a bad line.   In that case it won't be cell drops.

gert
--
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de

 
 
************************************************************************************
This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************




 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************




From zivl at gilat.net  Mon Sep 21 03:21:16 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Mon, 21 Sep 2009 10:21:16 +0300
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <DB9EA494D2E5614D842C2BC65C2D172288C951@mail-ww.vanoppen.com>
References: <4AAFD139.4050402@west.net><54B74A52-F9EC-47DD-92F9-97913A7026D7@wisc.edu>
	<4AB42BED.9070208@justinshore.com>
	<DB9EA494D2E5614D842C2BC65C2D172288C951@mail-ww.vanoppen.com>
Message-ID: <EC993E87D960A541A66BF21D62AA42A623015120BC@exch2k7.gilat.local>

Wanna know what is a good workaround?
Wait for Cisco webmonkeys to understand they screwed up and fix it.
In the meantime...
Get the MD5SUM of the file you want to download.
Search the IOS file on the P2P cloud (Bitorrent is the best)
If you happen to find it, download it, very fast, and then do a MD5 check to see the file is genuine and unmodified...

That's what I did with my home router...

Use at your own risk!


 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************




From zivl at gilat.net  Mon Sep 21 03:24:08 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Mon, 21 Sep 2009 10:24:08 +0300
Subject: [c-nsp] fake-workaround ... Re:  "Enhanced" download procedure
In-Reply-To: <D49C1A85-BB57-42E0-8301-472E1A83A91E@puck.nether.net>
References: <98424577.1493471253223622619.JavaMail.root@zmail.newpaltz.edu>
	<alpine.BSF.2.00.0909181456280.34749@murf.icantclick.org>
	<D49C1A85-BB57-42E0-8301-472E1A83A91E@puck.nether.net>
Message-ID: <EC993E87D960A541A66BF21D62AA42A623015120BD@exch2k7.gilat.local>

That will be called the "D-Day" ?? :-)


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jared Mauch
Sent: Friday, September 18, 2009 10:15 PM
To: david raistrick
Cc: cisco-nsp at puck.nether.net
Subject: [c-nsp] fake-workaround ... Re: "Enhanced" download procedure

So when you get to the following page where it says "If your download  
does not start "click here", you can "view source" with your web  
browser, and look for the following important components:

eg:

fileName":"s72033-advipservicesk9-mz.122-33.SXI2a.bin"
filePath":"/swc/esd/03/crypto/3DES/281569550/contract"
ftpServerName":"download-sj.cisco.com"

If you go ahead and combine these into:

http://download-sj.cisco.com/swc/esd/03/crypto/3DES/281569550/contract/s72033-advipservicesk9-mz.122-33.SXI2a.bin 
  you can use LYNX (if it has SSL support) still to do the siteminder  
cookie fu and fetch your image.

Why they won't just expose these links directly is foolish and a  
problem.

I do suggest we have a "download-day" where everyone opens a tac case  
at the same time to get the direct link to images.

- Jared

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************




 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************




From koug at intracom.gr  Mon Sep 21 04:02:49 2009
From: koug at intracom.gr (John Kougoulos)
Date: Mon, 21 Sep 2009 11:02:49 +0300 (GTB Daylight Time)
Subject: [c-nsp] Router logs going to dmesg
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AAC3C@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE044AAC3C@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <alpine.WNT.2.00.0909211057420.2104@pckoug1.intranet.gr>

Hello,

somewhere at the start of syslog.conf you will see something like:
*.err                      /dev/sysmsg
*err;kern.debug		   /var/adm/messages

*.alert;kern.err	  operator
etc.

change it to something like:
*.err;local0.none	      /dev/sysmsg
*err;kern.debug;local0.none   /var/adm/messages

etc.

and then pkill -1 syslogd

Regards,
John

On Mon, 21 Sep 2009, Andy Saykao wrote:

> Hi All,
>
> I'm trying to send cisco logs to a syslog server running Solaris 9. It's
> logging fine except that I'm seeing some logs showing up in dmesg.
>
> Example of a dmesg outout:
>
> Sep 21 13:44:16 [172.16.9.18.224.173] 3297: Sep 21 13:44:15.981 AEST:
> %LINK-3-UPDOWN: Interface GigabitEthernet0/45, changed state to down
> Sep 21 13:44:21 [172.16.9.18.224.173] 3298: Sep 21 13:44:20.956 AEST:
> %LINK-3-UPDOWN: Interface GigabitEthernet0/45, changed state to up
> Sep 21 13:48:38 agr1-cr-loopback-0.x.x.x 315047: Sep 21 13:48:37.756
> AEST: %SNMP-3-AUTHFAIL: Authentication failure for SNMP req from host
> 83.143.128.1
>
> I've tried changing the facility to local0.info on the cisco devices but
> still the same thing is happening. Is there a particular facility I
> should be using so the logs don't appear in dmesg???
>
> This was the only thing I could find on goggle about my problem but no
> real solution.
>
> http://www.velocityreviews.com/forums/t34315-which-facility-is-best-for-
> logging-to-linux-syslog.html
>
>
> This is my /etc/syslog.conf file.
>
> # Log cisco routers
> local0.info                                     /var/log/cisco.log
>
>
> And my config on the routers.
>
> logging facility local0
> logging source-interface Loopback0
> logging 210.15.210.x
>
> Thanks.
>
> Andy
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> Please notify the sender immediately by email if you have received this
> email by mistake and delete this email from your system. 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 organisation.
> Finally, the recipient should check this email and any attachments for
> the presence of viruses. The organisation accepts no liability for any
> damage caused by any virus transmitted by this email.
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From mtinka at globaltransit.net  Mon Sep 21 01:12:36 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 21 Sep 2009 13:12:36 +0800
Subject: [c-nsp] Cisco IPSec/VPN + DNS - Issue
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E140124C103D977@zy-ex1.zyedge.local>
References: <200909141847.22300.mtinka@globaltransit.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E140124C103D977@zy-ex1.zyedge.local>
Message-ID: <200909211312.41284.mtinka@globaltransit.net>

Just an update on this for the archives:

Turned out to be one of the DNS servers specified in the 
information pushed by the IPSec/VPN server was not 
configured to provide recursive look-ups for the address 
space assigned to users when they connect to the VPN.

Figured it out when moving the DNS server IP addresses 
around with the SSL/VPN as well.

I suppose what threw me off is the fact that Cisco seem to 
have scenarios where the VPN works, but DNS doesn't.

Our Systems Administrators will be fixing the recursive 
ACL's.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090921/510b51ac/attachment.bin>

From mtinka at globaltransit.net  Mon Sep 21 03:39:33 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 21 Sep 2009 15:39:33 +0800
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
	on this?
In-Reply-To: <Pine.LNX.4.64.0909210045430.6983@whammy.cluebyfour.org>
References: <027701ca3a3b$1164ca60$342e5f20$@com> <4AB6EAC9.6070101@utc.edu>
	<Pine.LNX.4.64.0909210045430.6983@whammy.cluebyfour.org>
Message-ID: <200909211540.02130.mtinka@globaltransit.net>

On Monday 21 September 2009 12:58:05 pm Justin M. Streiner 
wrote:

> I've run into this in the past with different vendors,
> even on occasions when the most frequently needed
> information ("show tech", "request tech-support", etc...)
> is attached to the support case before it gets assigned
> to an engineer.  A response like the one that was
> previously posted indicates that the engineer who handled
> the case failed to look at those attachments, wasting
> time and effort on both sides.

Same here; and we've seen this both for Cisco and other 
vendors.

We spend the time to post the usual details support 
engineers would need when we first submit the case, i.e.:

	o software version
	o platform type/model
	o status before issue
	o status during issue
	o mitigating actions taken to resolve issue
	o current status
	o any changes that could be impacting
	o how badly the network is affected
	o what the impact may mean for business
	o e.t.c.

... and then we get back a list of questions asking us the 
very things we've submitted. Many times, I've sent back an 
e-mail to the support engineers asking them to read my 
submission and then come back to me - and it works, although 
I'd rather not waste time doing that.

Given how difficult dealing with TAC(s) can be via e-mail, 
we've never engaged them on phone, unless when they call us 
to run labs, fortunately or otherwise.

It could be a lot better...

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090921/bd6ee19b/attachment.bin>

From A.L.M.Buxey at lboro.ac.uk  Mon Sep 21 04:24:54 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Mon, 21 Sep 2009 09:24:54 +0100
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten
	me	on this?
In-Reply-To: <027701ca3a3b$1164ca60$342e5f20$@com>
References: <027701ca3a3b$1164ca60$342e5f20$@com>
Message-ID: <20090921082454.GB25187@lboro.ac.uk>

hi,

the webex option is worrying when you have a core failure
(and therefore network is unknown useable status)
I think a large swathe of support is going the webex route
where they get you to log in and then they poke around
your system using predetermined flow chart of things to check
(i've been on the end of 2 of these recently - the end 
result being ' yes, it is configured as you say and tech-support
shows, and yes we do see the same error message as you  :-| )

but regarding the phone call - its not quite 'native English-speaking'
that you are after per-se.... what the issue is is regional
accents - strong accents and pronunciation can make for very difficult
and strained conversations.. believe me - we have 'native English speakers'
all over the UK who can be very difficult to fathom - many times I have
been chatting to support staff in Scotland, Nthn Ireland etc and i just cant
make out certain words/phrases so have to 'replay' the words i did make 
out to make out what they've said - and Tyneside and Merseyside accents
can be just as bad ;-)

unfortunately, with 'worldwide' companies and support this situation
will become more common.... salaries in the 'up and coming' economic
zones are $$cheap$$ and working rules/protection very weak... out of
hours working is not eg double time or time off in lieu. and VOIP
technology lets this play out cheaply too. They can probably train up
and hire 4 or 5 Eastern engineers for the price of a Euro or US
engineer on the phone (an Engineer limited to ~39hours /week and well
paid overtime/out of hours coverage etc)


anyway, technically - you booted your 6500's into a new IOS...they
actually came up, switched/routed for some time and THEN dropped back
to ROMMON mode?

alan

From tomas at soitron.com  Mon Sep 21 04:56:48 2009
From: tomas at soitron.com (Daniska, Tomas)
Date: Mon, 21 Sep 2009 10:56:48 +0200
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten
	meon this?
In-Reply-To: <200909211540.02130.mtinka@globaltransit.net>
References: <027701ca3a3b$1164ca60$342e5f20$@com>
	<4AB6EAC9.6070101@utc.edu><Pine.LNX.4.64.0909210045430.6983@whammy.cluebyfour.org>
	<200909211540.02130.mtinka@globaltransit.net>
Message-ID: <6B43981C32F8464CB24CEE209DA32BD3025A2633@kenya.tronet.as>

on the other hand,

I open all of my cases with all relevant information and as explanatory
comments as possible. *AND* I immediately call the dispatcher and ask
for the case be requeued to Brussels. Simple, effective. I've yet to see
an engineer from bru ignoring the information that's pre-attached. And
in bru, even the first-line engs are reasonable enough to call in their
escallation as soon as they get into the picture and see if they can
help with the issue themselves.


(btw - asking for requeue to bru is what everybody reasonable at Cisco
recommends to do - of course for europe...)

--

deejay


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Mark Tinka
> Sent: Monday, September 21, 2009 9:40 AM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Cisco TAC issues - can someone from Cisco
> enlighten meon this?
> 
> On Monday 21 September 2009 12:58:05 pm Justin M. Streiner
> wrote:
> 
> > I've run into this in the past with different vendors,
> > even on occasions when the most frequently needed
> > information ("show tech", "request tech-support", etc...)
> > is attached to the support case before it gets assigned
> > to an engineer.  A response like the one that was
> > previously posted indicates that the engineer who handled
> > the case failed to look at those attachments, wasting
> > time and effort on both sides.
> 
> Same here; and we've seen this both for Cisco and other
> vendors.
> 
> We spend the time to post the usual details support
> engineers would need when we first submit the case, i.e.:
> 
> 	o software version
> 	o platform type/model
> 	o status before issue
> 	o status during issue
> 	o mitigating actions taken to resolve issue
> 	o current status
> 	o any changes that could be impacting
> 	o how badly the network is affected
> 	o what the impact may mean for business
> 	o e.t.c.
> 
> ... and then we get back a list of questions asking us the
> very things we've submitted. Many times, I've sent back an
> e-mail to the support engineers asking them to read my
> submission and then come back to me - and it works, although
> I'd rather not waste time doing that.
> 
> Given how difficult dealing with TAC(s) can be via e-mail,
> we've never engaged them on phone, unless when they call us
> to run labs, fortunately or otherwise.
> 
> It could be a lot better...
> 
> Cheers,
> 
> Mark.
> 
> 
> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 4437
> (20090918) __________
> 
> Tuto spravu preveril ESET NOD32 Antivirus.
> 
> http://www.eset.sk
> 
 

__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4437
(20090918) __________

Tuto spravu preveril ESET NOD32 Antivirus.

http://www.eset.sk
 

From kevin at gannons.net  Mon Sep 21 05:00:35 2009
From: kevin at gannons.net (kevin gannon)
Date: Mon, 21 Sep 2009 10:00:35 +0100
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
	on this?
In-Reply-To: <20090921082454.GB25187@lboro.ac.uk>
References: <027701ca3a3b$1164ca60$342e5f20$@com>
	<20090921082454.GB25187@lboro.ac.uk>
Message-ID: <17eef0950909210200la903293idc49dd7f85d4f593@mail.gmail.com>

There is always a Duty Manager available to escalate faults.
They are non technical but there job is get you the support
you need in critical situations. In the 10 years I have been
dealing daily with the TAC I have spoken to them may 5
times and each time they have done the business.

Regards
Kevin

On Mon, Sep 21, 2009 at 9:24 AM, Alan Buxey <A.L.M.Buxey at lboro.ac.uk> wrote:

> hi,
>
> the webex option is worrying when you have a core failure
> (and therefore network is unknown useable status)
> I think a large swathe of support is going the webex route
> where they get you to log in and then they poke around
> your system using predetermined flow chart of things to check
> (i've been on the end of 2 of these recently - the end
> result being ' yes, it is configured as you say and tech-support
> shows, and yes we do see the same error message as you  :-| )
>
> but regarding the phone call - its not quite 'native English-speaking'
> that you are after per-se.... what the issue is is regional
> accents - strong accents and pronunciation can make for very difficult
> and strained conversations.. believe me - we have 'native English speakers'
> all over the UK who can be very difficult to fathom - many times I have
> been chatting to support staff in Scotland, Nthn Ireland etc and i just
> cant
> make out certain words/phrases so have to 'replay' the words i did make
> out to make out what they've said - and Tyneside and Merseyside accents
> can be just as bad ;-)
>
> unfortunately, with 'worldwide' companies and support this situation
> will become more common.... salaries in the 'up and coming' economic
> zones are $$cheap$$ and working rules/protection very weak... out of
> hours working is not eg double time or time off in lieu. and VOIP
> technology lets this play out cheaply too. They can probably train up
> and hire 4 or 5 Eastern engineers for the price of a Euro or US
> engineer on the phone (an Engineer limited to ~39hours /week and well
> paid overtime/out of hours coverage etc)
>
>
> anyway, technically - you booted your 6500's into a new IOS...they
> actually came up, switched/routed for some time and THEN dropped back
> to ROMMON mode?
>
> alan
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From asturluismi at gmail.com  Mon Sep 21 06:01:08 2009
From: asturluismi at gmail.com (luismi)
Date: Mon, 21 Sep 2009 12:01:08 +0200
Subject: [c-nsp] IOS for 7206VXR, SRD2a or SRC4?
Message-ID: <1253527268.7611.1.camel@dsba-ipso>

Hi all,

Any recommendation of an IOS for a 7206VXR?
I was using the features navigator and I saw that SRD2a and SRC4 are
mostly the same so, what are the differences between both of them?

Thanks in advance.


From gert at greenie.muc.de  Mon Sep 21 06:18:41 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 21 Sep 2009 12:18:41 +0200
Subject: [c-nsp] IOS for 7206VXR, SRD2a or SRC4?
In-Reply-To: <1253527268.7611.1.camel@dsba-ipso>
References: <1253527268.7611.1.camel@dsba-ipso>
Message-ID: <20090921101841.GK1508@greenie.muc.de>

Hi,

On Mon, Sep 21, 2009 at 12:01:08PM +0200, luismi wrote:
> Any recommendation of an IOS for a 7206VXR?

What exactly are you planning to use the box for?

> I was using the features navigator and I saw that SRD2a and SRC4 are
> mostly the same so, what are the differences between both of them?

We're using 12.3 and 12.4 mainline with good success for "basic IPv4, IPv6, 
L2TP termination" stuff.  So it really depends on "what is the box supposed
to do".

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090921/eb576fe7/attachment.bin>

From asturluismi at gmail.com  Mon Sep 21 06:25:43 2009
From: asturluismi at gmail.com (luismi)
Date: Mon, 21 Sep 2009 12:25:43 +0200
Subject: [c-nsp] IOS for 7206VXR, SRD2a or SRC4?
In-Reply-To: <20090921101841.GK1508@greenie.muc.de>
References: <1253527268.7611.1.camel@dsba-ipso>
	<20090921101841.GK1508@greenie.muc.de>
Message-ID: <1253528743.7418.2.camel@dsba-ipso>

yes, I know we are going to use...

EIGRP, BGP, ACL, PBR, reflexive ACLs, HSRP, GRE tunnels, multicast,
VRFs, EEM, SLA, SNMP, Netflow...

I would like to go also for BFD, OSPF and/or MP-BGP in the future.


From dwinkworth at att.net  Mon Sep 21 08:32:14 2009
From: dwinkworth at att.net (Derick Winkworth)
Date: Mon, 21 Sep 2009 05:32:14 -0700 (PDT)
Subject: [c-nsp] IOS for 7206VXR, SRD2a or SRC4?
In-Reply-To: <1253528743.7418.2.camel@dsba-ipso>
References: <1253527268.7611.1.camel@dsba-ipso>
	<20090921101841.GK1508@greenie.muc.de>
	<1253528743.7418.2.camel@dsba-ipso>
Message-ID: <197552.2716.qm@web180016.mail.gq1.yahoo.com>

12.4(15)T10

Its the third or fourth bug-fix only release in the 12.4(15)T line of code...

You have a lot of features you want to enable... I would try this one first..








________________________________
From: luismi <asturluismi at gmail.com>
To: Gert Doering <gert at greenie.muc.de>
Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
Sent: Monday, September 21, 2009 5:25:43 AM
Subject: Re: [c-nsp] IOS for 7206VXR, SRD2a or SRC4?

yes, I know we are going to use...

EIGRP, BGP, ACL, PBR, reflexive ACLs, HSRP, GRE tunnels, multicast,
VRFs, EEM, SLA, SNMP, Netflow...

I would like to go also for BFD, OSPF and/or MP-BGP in the future.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From andy.petrenko at gmail.com  Mon Sep 21 09:06:05 2009
From: andy.petrenko at gmail.com (Andrey 'sshd' Petrenko)
Date: Mon, 21 Sep 2009 16:06:05 +0300
Subject: [c-nsp] IOS for 7206VXR, SRD2a or SRC4?
In-Reply-To: <197552.2716.qm@web180016.mail.gq1.yahoo.com>
References: <1253527268.7611.1.camel@dsba-ipso>
	<20090921101841.GK1508@greenie.muc.de>
	<1253528743.7418.2.camel@dsba-ipso>
	<197552.2716.qm@web180016.mail.gq1.yahoo.com>
Message-ID: <6b300f5d0909210606m564f55b1m7f92d98311af9911@mail.gmail.com>

I using this software:
#sh ver | i IOS
IOS (tm) 7200 Software (C7200-JK9O3S-M), Version 12.3(15b), RELEASE SOFTWARE
(fc1)


2009/9/21 Derick Winkworth <dwinkworth at att.net>

> 12.4(15)T10
>
> Its the third or fourth bug-fix only release in the 12.4(15)T line of
> code...
>
> You have a lot of features you want to enable... I would try this one
> first..
>
>
>
>
>
>
>
>
> ________________________________
> From: luismi <asturluismi at gmail.com>
> To: Gert Doering <gert at greenie.muc.de>
> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Sent: Monday, September 21, 2009 5:25:43 AM
> Subject: Re: [c-nsp] IOS for 7206VXR, SRD2a or SRC4?
>
> yes, I know we are going to use...
>
> EIGRP, BGP, ACL, PBR, reflexive ACLs, HSRP, GRE tunnels, multicast,
> VRFs, EEM, SLA, SNMP, Netflow...
>
> I would like to go also for BFD, OSPF and/or MP-BGP in the future.
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



-- 
With best regards,
     Andrey 'sshd' Petrenko
     xmmp: sshd at jabber.org
     gtalk: andy.petrenko at gmail.com
     skype: andy.petrenko
     web: http://sshd.by

From SPfister at dps.k12.oh.us  Mon Sep 21 09:15:14 2009
From: SPfister at dps.k12.oh.us (Steven Pfister)
Date: Mon, 21 Sep 2009 09:15:14 -0400
Subject: [c-nsp] Need help troubleshooting CRC errors
In-Reply-To: <A596D325B2894B7EA8AE1FFFBE900B7E@int.convex.pt>
References: <4AB211D9.9E6F.00B8.0@dps.k12.oh.us>
	<436848D1ED9646638E260E7AE456D593@int.convex.pt>
	<4AB39469.9E6F.00B8.0@dps.k12.oh.us>
	<A596D325B2894B7EA8AE1FFFBE900B7E@int.convex.pt>
Message-ID: <4AB74414.9E6F.00B8.0@dps.k12.oh.us>

The 3640 has a ATM 1A-OC3MM. The 1500 MTU is hard coded in the config. These sites were all set up before I started here 2 years ago. We're gradually replacing the ATM at the older sites with CSME.

thanks!

Steve Pfister
Technical Coordinator, 
The Office of Information Technology
Dayton Public Schools
115 S. Ludlow St. 
Dayton, OH 45402
 
Office (937) 542-3149
Cell (937) 673-6779
Direct Connect: 137*131747*8
Email spfister at dps.k12.oh.us


>>> "Antonio Soares" <amsoares at netcabo.pt> 9/18/2009 7:08 PM >>>
This document might help you:

Understanding Maximum Transmission Unit (MTU) on ATM Interfaces

http://www.cisco.com/en/US/tech/tk39/tk371/technologies_tech_note09186a00800c8279.shtml 

This is what it says about Length Violations:

"A router increments the AAL5 length violation counter when the calculated size of a reassembled packet fails to match the received
value of the AAL5 length field regardless of the MTU. To understand how these violations can occur, you need to understand how a
receiving ATM interface recognizes the last cell of a frame."

What ATM NM do you have in the 3640 ? Did you change the default MTU from 4470 to 1500 ?



Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt 

-----Original Message-----
From: Steven Pfister [mailto:SPfister at dps.k12.oh.us] 
Sent: sexta-feira, 18 de Setembro de 2009 19:09
To: Antonio Soares; cisco-nsp at puck.nether.net 
Subject: RE: [c-nsp] Need help troubleshooting CRC errors

Thanks for the link... I have a little more detail about the problem now:

'show atm pvc x/y' shows:

CrcErrors: 69402, SarTimeOuts: 2, OverSizedSDUs: 0, LengthViolation: 69294, CPIErrors: 0

Also, the router side shows, on 'show int':

  MTU 1500 bytes, sub MTU 1500, BW 155000 Kbit, DLY 80 usec,

router side, on 'show atm int atm':

Max. Datagram Size: 1558

8510 switch side, on 'show int':

  MTU 4470 bytes, sub MTU 4470, BW 155520 Kbit, DLY 0 usec,

Would this be a problem?

Steve Pfister
Technical Coordinator,
The Office of Information Technology
Dayton Public Schools
115 S. Ludlow St. 
Dayton, OH 45402
 
Office (937) 542-3149
Cell (937) 673-6779
Direct Connect: 137*131747*8
Email spfister at dps.k12.oh.us 


>>> "Antonio Soares" <amsoares at netcabo.pt> 9/17/2009 11:45 AM >>>
Try this document:

CRC Troubleshooting Guide for ATM Interfaces

http://www.cisco.com/en/US/tech/tk39/tk48/technologies_tech_note09186a00800c93ef.shtml 


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Steven Pfister
Sent: quinta-feira, 17 de Setembro de 2009 15:39
To: cisco-nsp at puck.nether.net 
Subject: [c-nsp] Need help troubleshooting CRC errors

Some of our older remote sites are connected via ATM. Two or three T1s come into an Cisco 8510, and from there a 155mbps OC3
connection over fiber to a 3640 router. Lately, I've been noticing that pretty much every one of them is showing what I think is a
rather high receive error count on the 3640 end of the OC3 connection, and it all seems to be CRC errors. Not much of any errors are
showing up on the 8510 end of the OC3 connection. For example, one site yesterday late afternoon showed 63, 763 receive errors for
the day. Several others were in the 20Ks. I'm not really certain what the cause might be, or where to start. Can anyone help?

Thanks!


Steve Pfister
Technical Coordinator,
The Office of Information Technology
Dayton Public Schools
115 S. Ludlow St. 
Dayton, OH 45402
 
Office (937) 542-3149
Cell (937) 673-6779
Direct Connect: 137*131747*8
Email spfister at dps.k12.oh.us 


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp 
archive at http://puck.nether.net/pipermail/cisco-nsp/ 






From sfischer1967 at gmail.com  Mon Sep 21 09:31:48 2009
From: sfischer1967 at gmail.com (Steven Fischer)
Date: Mon, 21 Sep 2009 09:31:48 -0400
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
	on this?
In-Reply-To: <20090921082454.GB25187@lboro.ac.uk>
References: <027701ca3a3b$1164ca60$342e5f20$@com>
	<20090921082454.GB25187@lboro.ac.uk>
Message-ID: <500ffb690909210631n158f65ceob056bace17ce666c@mail.gmail.com>

as an aside, the TAC engineer (Indian engineer #4) stuck with it, and has
found the bug that was causing the meltdown.  Credit certainly needs to be
given for that.

On Mon, Sep 21, 2009 at 4:24 AM, Alan Buxey <A.L.M.Buxey at lboro.ac.uk> wrote:

> hi,
>
> the webex option is worrying when you have a core failure
> (and therefore network is unknown useable status)
> I think a large swathe of support is going the webex route
> where they get you to log in and then they poke around
> your system using predetermined flow chart of things to check
> (i've been on the end of 2 of these recently - the end
> result being ' yes, it is configured as you say and tech-support
> shows, and yes we do see the same error message as you  :-| )
>
> but regarding the phone call - its not quite 'native English-speaking'
> that you are after per-se.... what the issue is is regional
> accents - strong accents and pronunciation can make for very difficult
> and strained conversations.. believe me - we have 'native English speakers'
> all over the UK who can be very difficult to fathom - many times I have
> been chatting to support staff in Scotland, Nthn Ireland etc and i just
> cant
> make out certain words/phrases so have to 'replay' the words i did make
> out to make out what they've said - and Tyneside and Merseyside accents
> can be just as bad ;-)
>
> unfortunately, with 'worldwide' companies and support this situation
> will become more common.... salaries in the 'up and coming' economic
> zones are $$cheap$$ and working rules/protection very weak... out of
> hours working is not eg double time or time off in lieu. and VOIP
> technology lets this play out cheaply too. They can probably train up
> and hire 4 or 5 Eastern engineers for the price of a Euro or US
> engineer on the phone (an Engineer limited to ~39hours /week and well
> paid overtime/out of hours coverage etc)
>
>
> anyway, technically - you booted your 6500's into a new IOS...they
> actually came up, switched/routed for some time and THEN dropped back
> to ROMMON mode?
>
> alan
>



-- 
To him who is able to keep you from falling and to present you before his
glorious presence without fault and with great joy

From asturluismi at gmail.com  Mon Sep 21 09:32:59 2009
From: asturluismi at gmail.com (luismi)
Date: Mon, 21 Sep 2009 15:32:59 +0200
Subject: [c-nsp] IOS for 7206VXR, SRD2a or SRC4?
In-Reply-To: <197552.2716.qm@web180016.mail.gq1.yahoo.com>
References: <1253527268.7611.1.camel@dsba-ipso>
	<20090921101841.GK1508@greenie.muc.de>
	<1253528743.7418.2.camel@dsba-ipso>
	<197552.2716.qm@web180016.mail.gq1.yahoo.com>
Message-ID: <1253539979.7418.11.camel@dsba-ipso>

I didn't tell you, it is a NPE-G2 

El lun, 21-09-2009 a las 05:32 -0700, Derick Winkworth escribi?:
> 12.4(15)T10
> 
> Its the third or fourth bug-fix only release in the 12.4(15)T line of
> code...
> 
> You have a lot of features you want to enable... I would try this one
> first..
> 
> 
> 
> 
> 
> 
> 
> ______________________________________________________________________
> From: luismi <asturluismi at gmail.com>
> To: Gert Doering <gert at greenie.muc.de>
> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Sent: Monday, September 21, 2009 5:25:43 AM
> Subject: Re: [c-nsp] IOS for 7206VXR, SRD2a or SRC4?
> 
> yes, I know we are going to use...
> 
> EIGRP, BGP, ACL, PBR, reflexive ACLs, HSRP, GRE tunnels, multicast,
> VRFs, EEM, SLA, SNMP, Netflow...
> 
> I would like to go also for BFD, OSPF and/or MP-BGP in the future.
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


From asaudale at gmail.com  Mon Sep 21 09:43:33 2009
From: asaudale at gmail.com (asaudale at gmail.com)
Date: Mon, 21 Sep 2009 13:43:33 +0000
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
	onthis?
In-Reply-To: <027701ca3a3b$1164ca60$342e5f20$@com>
References: <027701ca3a3b$1164ca60$342e5f20$@com>
Message-ID: <68231421-1253540264-cardhu_decombobulator_blackberry.rim.net-1673950434-@bda046.bisx.prodap.on.blackberry>


THE BEST way to work with TAC and possibly anticipate failure in your case is (assuming you don't have backup 6500 to load the intended image in lab) :


1. Open up the TAC case 3 - 4 hrs before upgrading through the web (open w/ P2)

2. Provide all necessary information through web (these information will go through system before reaching the correct guy) 

3. If an engineer has been assigned, call him up and tell him about your upgrade plan. (In this time, you can ensure yourself there's not any communication issue)  If you're not happy with the assigned engineer, call duty manager to get native speaker. 

4. Only after you've found TAC engineer you're comfortable (tech & language) with, get him to understand your plan (details), and get him remote access to console your 6500. Don't forget to get his desk number as well. If everything is settled, ask him to wait when the maintenance window comes  and leave the case  as P2. 

5. You upgrade 6500 during the window, when problems come. Call up the engineer, tell your problem and if necessary ask him to console in to your core switch.(Or ask him right away)
 
I'm sure you'll get appropriate TAC help within minutes.


Asa







Powered by Telkomsel BlackBerry?

-----Original Message-----
From: "Steve Fischer" <sfischer1967 at gmail.com>
Date: Sun, 20 Sep 2009 17:41:08 
To: <cisco-nsp at puck.nether.net>
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me on
	this?

Last Thursday evening, at around midnight, in the course of my organizations
network maintenance, we had not one but two of our core 6500 switches go
into ROMMON (after being rebooted with new code, and being operational for
approximately 45 minutes)at the same time and for no apparent reason.
Attempts to reboot the devices were in vain, and attempts to roll-back also
appeared to be in vain, so I called the Cisco TAC and opened a P1 case.
Immediately, the call was routed over to India.  I was in a loud data
center, and the engineers accent was very thick, to the point I could not
hear him over the background noise, much less understand him.  Other than
asking for a webex session - made impossible by the fact that the network
core is down, he offers nothing in the way of assistance.

 

I asked to have the case transferred to a native-English speaking engineer.
Call transferred to Indian engineer #2, and the communications issues
persist.  I have two core switches down, and am becoming more than a little
concerned.  Same result - engineer really offers nothing in the way of
assistance, and I again, request the call to be transferred to a
native-English speaking engineer.  Enter Indian engineer #3.  Now let me
state here for the record that I am in no way questioning the competence of
the three gentlemen I spoke to, nor do I have any xenophobic tendencies, but
I would like to make a few points here:

 

1.       If I cannot understand the support engineer, it will be difficult
for him to assist me, regardless of his skill level.

2.       Having a native-English speaking engineer available would have been
at this time very disarming, and calming in the midst of for what was for me
a crisis.  In the medical field, they call it bed-side manner, which would
have been of immense value given the crisis I was facing.

3.       My organization spends well over $100K annually in Cisco
maintenance.

 

Case transferred to Indian engineer #4.  Now, while this was occurring, I
called Cisco's TAC and asked the case be re-queued to an engineer in North
America.  I was told that there were no support engineers on duty in North
America.  Now, I'm getting upset, and more than just a little. Also, in the
meantime, it was suggested that I remove one of the CompactFlash cards from
one of the 6500's that was still working (we have 4 total), and try to boot
from the IOS image on it.  Upon ejecting the Flash card, that 6500 too, went
immediately into ROMMON.  So, now, we have 3 of 4 core switches down.  The
entire data center is down, and are one step away from the phone system
going down as well - which indeed did happen.  As we now have all four cores
down, the options of rebooting them with the old code. One by one, through
all four cores, they are rolled back, and finally the network comes up.  Let
me say the fourth engineer suggested this, by prior to that, I had concluded
this was going to be the best course of action.

 

Now, back up two weeks.  I had a Cisco Works issue at around 3:00PM EST, and
open a case for it.  The call is transferred to.wait for it.India.  So, it
doesn't appear that the time of an issue completely influences to what Cisco
support center a call is routed.  As a matter of fact, the support engineer
for that particular call informed me it was 2:00AM where he was.  

 

This leads me to several questions that perhaps someone from Cisco
monitoring this forum could answer.

 

1.       Given the stature of the 6500 platform within Cisco's product line,
and given the severity of the issue I was experiencing, is there no Cisco
Support Center in North America staffed 24X7X365 to deal with such issues?

2.       Was the only option available to me a webex session?  It seemed
strange that the engineer would even ask for that, given that this was
reported as a network down emergency.

3.       Upon asking the call be transferred to a native English speaking
engineer, why was the call routed to 3 more Indian engineers? Rather than
informing me that no native English-speaking engineers were available, why
did I have to request this three more times?  I find it INCREDIBLE that an
organization of Cisco's size could not find a single native English-speaking
engineer to assist me in this crisis concerning their flagship product.

4.       Does Cisco as a company understand the value of being disarming to
a stressed-out client in the midst of a crisis, and how much providing a
support engineer who can clearly and effectively communicate with the
customer?

 

If I were to grade Cisco on this support call, and to my knowledge, this was
the first network down call I've opened since I've been with this
organization, I'd give Cisco an F.no, an F-.  This was an epic-fail for
Cisco, to the point that my organization is considering dumping their
support all together, and going with a third party.  There is just no way I
should have been bounced to four Indian engineers when after the first one,
and the second one, I calmly explained the rationale behind requesting a
native English-speaking engineer.  

 

What can Cisco do to make this right?

 

1.       A written letter of apology.  I don't blame the engineers for this
- they are likely highly competent support engineers.  Cisco failed to
provide an engineer who could communicate with me clearly and concisely. 

2.       Provide an additional one year of maintenance coverage on all four
of our 6500's free of charge, as that pales by comparison to the amount of
money lost by my company for the two hours our network was down, and I was
unable to reach an engineer who could effectively communicate with me.

3.       Staff a support center in North America 24X7X365 geared to deal
with exactly the issue I encountered.  A P1 case should be treated
differently than a P3 case, and this case wasn't, at least not from my
perspective.

4.       When it became clear that the communications issues that existed
between the support engineer and myself precluded progress being made to
resolve the issue, and I requested the case be escalated, escalate the case.
I DO blame the engineer for that - not escalating the case when requested to
do so.    

5.       Stop making the first course of action being requesting a webex.
There will be scenarios where that won't be possible, as was the case
Thursday evening.  Engineer 1 seemed to give up when webex wasn't an option.

 

I am interested in any and all feedback from the community on this.  If
there is someone within Cisco (other than my salesperson, who's heard this
before from me.on more than one occasion) who I can send this to, and can
respond to it, it would also be appreciated.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From mtinka at globaltransit.net  Mon Sep 21 09:48:10 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 21 Sep 2009 21:48:10 +0800
Subject: [c-nsp] IOS for 7206VXR, SRD2a or SRC4?
In-Reply-To: <1253527268.7611.1.camel@dsba-ipso>
References: <1253527268.7611.1.camel@dsba-ipso>
Message-ID: <200909212148.17108.mtinka@globaltransit.net>

On Monday 21 September 2009 06:01:08 pm luismi wrote:

> Any recommendation of an IOS for a 7206VXR?
> I was using the features navigator and I saw that SRD2a
> and SRC4 are mostly the same so, what are the differences
> between both of them?

Would suggest SRC4, although SRC5 will be out end of 
October. Also, SRD3 is already out, but would not recommend 
it without going through this link first to make sure you 
need it for this platform:

http://www.cisco.com/en/US/docs/ios/12_2sr/release/notes/122SRrn.html

SRC4 contains mostly bug fixes since SRC3. No new features.

SRC has been out longer than SRD, and from the little I can 
infer so far, the 7600 may stand to benefit the most from 
SRD, than the 7200.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090921/af622aec/attachment.bin>

From mtinka at globaltransit.net  Mon Sep 21 09:58:50 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 21 Sep 2009 21:58:50 +0800
Subject: [c-nsp] IOS for 7206VXR, SRD2a or SRC4?
In-Reply-To: <197552.2716.qm@web180016.mail.gq1.yahoo.com>
References: <1253527268.7611.1.camel@dsba-ipso>
	<1253528743.7418.2.camel@dsba-ipso>
	<197552.2716.qm@web180016.mail.gq1.yahoo.com>
Message-ID: <200909212158.56879.mtinka@globaltransit.net>

On Monday 21 September 2009 08:32:14 pm Derick Winkworth 
wrote:

> 12.4(15)T10
>
> Its the third or fourth bug-fix only release in the
> 12.4(15)T line of code...
>
> You have a lot of features you want to enable... I would
> try this one first..

Before we started out with SRC, we evaluated a single code 
base that we could run on both our NPE-G1's and below, as 
well as the NPE-G2's and 7201's.

Needless to say, as do most folk, we tried to stay away from 
the T train, despite the fact that aside from SRC, 12.4T and 
12.4XD were the only other trains that supported the NPE-G2 
and 7201 platforms.

Moreover, we wanted BFD, and it seemed that only SRC (and 
now, SRD too) provided support for this across all interface 
types, including WAN's, i.e., Frame Relay, POS, Serial, ATM, 
e.t.c.

Our decision was clear after that. SRC has quite a 
comprehensive feature set, and because we can run it across 
the NPE-400, NPE-G1, NPE-G2 and 7201, it made for a great 
choice with us.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090921/7b2ef16a/attachment-0001.bin>

From mtinka at globaltransit.net  Mon Sep 21 10:00:34 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 21 Sep 2009 22:00:34 +0800
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
	on this?
In-Reply-To: <500ffb690909210631n158f65ceob056bace17ce666c@mail.gmail.com>
References: <027701ca3a3b$1164ca60$342e5f20$@com>
	<20090921082454.GB25187@lboro.ac.uk>
	<500ffb690909210631n158f65ceob056bace17ce666c@mail.gmail.com>
Message-ID: <200909212200.35552.mtinka@globaltransit.net>

On Monday 21 September 2009 09:31:48 pm Steven Fischer 
wrote:

> as an aside, the TAC engineer (Indian engineer #4) stuck
> with it, and has found the bug that was causing the
> meltdown.  Credit certainly needs to be given for that.

Good stuff.

Grateful if you could kindly share any technical experiences 
about this issue, in case any of us go through the same with 
our 6500 platforms. Thanks.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090921/cac3d5d9/attachment.bin>

From mtinka at globaltransit.net  Mon Sep 21 10:02:50 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 21 Sep 2009 22:02:50 +0800
Subject: [c-nsp] IOS for 7206VXR, SRD2a or SRC4?
In-Reply-To: <1253539979.7418.11.camel@dsba-ipso>
References: <1253527268.7611.1.camel@dsba-ipso>
	<197552.2716.qm@web180016.mail.gq1.yahoo.com>
	<1253539979.7418.11.camel@dsba-ipso>
Message-ID: <200909212202.51346.mtinka@globaltransit.net>

On Monday 21 September 2009 09:32:59 pm luismi wrote:

> I didn't tell you, it is a NPE-G2

Then your only options are:

12.4T, 12.4XD, SRC and SRD.

As mentioned before, SRC would be my recommendation. We've 
been happy with it.

I was going to warn you about staying away from BFD on the 
NPE-G1 and below, until SRC5. But since your platform is the 
NPE-G2, then you're in the clear re: the evil BFD-related 
crash (which only affects the NPE-G1).

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090921/0f30eb59/attachment.bin>

From sfischer1967 at gmail.com  Mon Sep 21 10:45:43 2009
From: sfischer1967 at gmail.com (Steven Fischer)
Date: Mon, 21 Sep 2009 10:45:43 -0400
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
	on this?
In-Reply-To: <200909212200.35552.mtinka@globaltransit.net>
References: <027701ca3a3b$1164ca60$342e5f20$@com>
	<20090921082454.GB25187@lboro.ac.uk>
	<500ffb690909210631n158f65ceob056bace17ce666c@mail.gmail.com>
	<200909212200.35552.mtinka@globaltransit.net>
Message-ID: <500ffb690909210745y7b69fa12n8ab12f27352fc9fe@mail.gmail.com>

the specific bug that caused my issue is *CSCta02715*
Now, I find it scary that a command element related to logging could take
down an array of 6500's.  Furthermore, we had been running the SXH5 code
with the "logging count" command element enabled on two of the four core
switches for 30 days (the code had actually been running for three months+)


logging count is a way to quickly check log messages on a switch/router, and
provides simple output that can be used to identify recurring and troubling
issues.

see:
http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_logging_count.html


On Mon, Sep 21, 2009 at 10:00 AM, Mark Tinka <mtinka at globaltransit.net>wrote:

> On Monday 21 September 2009 09:31:48 pm Steven Fischer
> wrote:
>
> > as an aside, the TAC engineer (Indian engineer #4) stuck
> > with it, and has found the bug that was causing the
> > meltdown.  Credit certainly needs to be given for that.
>
> Good stuff.
>
> Grateful if you could kindly share any technical experiences
> about this issue, in case any of us go through the same with
> our 6500 platforms. Thanks.
>
> Cheers,
>
> Mark.
>



-- 
To him who is able to keep you from falling and to present you before his
glorious presence without fault and with great joy

From justin at justinshore.com  Mon Sep 21 10:54:01 2009
From: justin at justinshore.com (Justin Shore)
Date: Mon, 21 Sep 2009 09:54:01 -0500
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco
 enlighten	meon this?
In-Reply-To: <6B43981C32F8464CB24CEE209DA32BD3025A2633@kenya.tronet.as>
References: <027701ca3a3b$1164ca60$342e5f20$@com>	<4AB6EAC9.6070101@utc.edu><Pine.LNX.4.64.0909210045430.6983@whammy.cluebyfour.org>	<200909211540.02130.mtinka@globaltransit.net>
	<6B43981C32F8464CB24CEE209DA32BD3025A2633@kenya.tronet.as>
Message-ID: <4AB79389.6080602@justinshore.com>

Daniska, Tomas wrote:
> (btw - asking for requeue to bru is what everybody reasonable at Cisco
> recommends to do - of course for europe...)

Does anyone know what the equivalent would be in the states?  I try my 
best to open cases first thing in the morning (CST) when I'm likely to 
get someone in the states.  That said I've still had my share of 
communication problems to overcome.  I had actually had to requeue cases 
twice because of communication issues.  I hated to do it but I needed 
help and I needed it right then.  I couldn't spend 3 or 4 times as much 
time trying to overcome that hurdle.  I had a case routed to Australia a 
few weeks ago.  I was thinking that this would be fine.  As it turns out 
she had one of the thickest accents I've ever heard.  She was not from 
Australia.  Fortunately she went on leave part way into my case (which 
was good because all I ever got from her was form letter replies, 
nothing helpful).  So I requeued on a Friday.  I got an engineer from 
SJC.  That Monday he sent me some more info and then also went on leave. 
  So I requeued for a 3rd time.  That engineer was very helpful and we 
managed to resolve the issue.  He went on leave as the case was wrapping 
up.  I wish I worked at Cisco and had all that PTO! :-)

Steve and everyone else:  when you feel like you're getting the 
run-around from TAC (it happens from time to time, even with the best of 
engineers) you need to ask for the Duty Manager.  If the TAC engineer 
won't connect you with that person or doesn't know who it is grab 
another phone and call back into Cisco.  Give the case dispatch person 
your SR and ask for the Duty Manager.  Explain what you think is going 
off track with the case and what you feel would be the appropriate way 
to proceed.  They should be able to help; it's their job.

I've had to involve the Duty Manager a couple times on highly complex 
issues that involved multiple technologies.  For example I'm calling in 
about an IPSec SPA issue in a 7600 and because it's a 7600 I got routed 
to the switching group.  I need people from both groups and then some to 
effectively troubleshoot the problem.  After a few hours of the 
switching person beating on the problem it was clear to me that he 
didn't have the skills needed to troubleshoot the IPSec SPA. 
Unfortunately he didn't want to involve the other group.  I didn't have 
time to wait for him to come to the same realization that I had so I had 
the Duty Manager do it for him.  The VPN Specialist that they got on the 
phone was extremely helpful in troubleshooting the problem.  We'd have 
hours waiting on the switching guy to escalate the problem if I hadn't 
escalated the case to the duty manager.  Sometimes we engineers are 
reluctant to ask for help.

On the whole I usually have good luck when I call TAC.  Here lately I 
haven't had as good of luck but usually it's not a problem.  The 
engineer frequently leads me to discover what the problem is; I just 
needed someone to bounce ideas off of and talk the problem out. 
Occasionally I'll get an excellent engineer who is extremely deep in the 
technology at hand and he quite literally schools me.  That happens far 
less often I'm afraid.

Justin

PS==>  Ask for the Duty Manager....


From ler762 at gmail.com  Mon Sep 21 10:06:04 2009
From: ler762 at gmail.com (Lee)
Date: Mon, 21 Sep 2009 10:06:04 -0400
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
	on this?
In-Reply-To: <f9a8f300909201533h1698580fq293e5f5c9ffd6edd@mail.gmail.com>
References: <027701ca3a3b$1164ca60$342e5f20$@com>
	<f9a8f300909201533h1698580fq293e5f5c9ffd6edd@mail.gmail.com>
Message-ID: <dd5f2deb0909210706r2dc89f18kf46d69b144f85151@mail.gmail.com>

On Sun, Sep 20, 2009 at 6:33 PM, William McCall <william.mccall at gmail.com>wrote:

> I would advise you to make sure to fill out the eval among other
> things. This is a situation where I'd put all 1's. Make sure to put in
> the comments too.
>

I've been told the bingo scores apply only to the TAC engineer.  Giving him
a bad score because of management decisions that he had no control over
seems unfair.  I want something that lets me rate how well Cisco handled the
case - not just how well the engineer handled the case.

Lee


> Those evals (known as BINGOs internally) are a big deal and may help
> you with getting some motion.
>
> Of course, follow up with your AM and see what they can do.
>
>

From will at thoughtcrime.net  Mon Sep 21 11:34:37 2009
From: will at thoughtcrime.net (Byrd, William)
Date: Mon, 21 Sep 2009 10:34:37 -0500 (CDT)
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten
 meon this?
Message-ID: <1253547277.v2.mailanyonewebmail-222491@fuse49>

Ask your account team to sign you up for the Walker Survey. That's what
it's for and you can say whatever you want. Typically you get to review
every aspect of your service with Cisco in the yearly version although
they have different versions they do send out that may specifically
reference one part of your service i.e. Advanced Services contract, sales
engineer, etc.

HTH

-Will

----- Original Message -----
From: "Lee" <ler762 at gmail.com>
Sent: Mon, September 21, 2009 10:06
Subject:Re: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten
meon this?


On Sun, Sep 20, 2009 at 6:33 PM, William McCall
<william.mccall at gmail.com>wrote:

> I would advise you to make sure to fill out the eval among other
> things. This is a situation where I'd put all 1's. Make sure to put in
> the comments too.
>

I've been told the bingo scores apply only to the TAC engineer.  Giving him
a bad score because of management decisions that he had no control over
seems unfair.  I want something that lets me rate how well Cisco handled the
case - not just how well the engineer handled the case.

Lee


> Those evals (known as BINGOs internally) are a big deal and may help
> you with getting some motion.
>
> Of course, follow up with your AM and see what they can do.


From bacon at walleyesoftware.com  Mon Sep 21 12:08:30 2009
From: bacon at walleyesoftware.com (Jeff Bacon)
Date: Mon, 21 Sep 2009 11:08:30 -0500
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco
	enlighten	meon this?
In-Reply-To: <mailman.1.1253548800.62389.cisco-nsp@puck.nether.net>
References: <mailman.1.1253548800.62389.cisco-nsp@puck.nether.net>
Message-ID: <5A69C25361FED34F83ABF05F5047524505CD88A7@wally.walleyetrading.net>

You guys are starting to frighten me. I've got 6500s running H4, I1 and
I2, and it's hard for me to say which of any of the releases are any
good - meanwhile, the TAC is busy chasing down why they're randomly
corrupting my NAT tables. 

(I finally got a full capture of the incident where very clearly the
6500 had confused packets associated with one NAT flow with another
flow, resulting in packets from one TCP session getting sent to another
host and other packets going to the right internal destination with a
src of another internal host. Nice. It only happens once every 2-3 weeks
tho!)

I wanted SXI for something, I can't remember what - maybe I should have
stayed back at SXF8. :( 

 
> the specific bug that caused my issue is *CSCta02715*
> Now, I find it scary that a command element related to logging could
take
> down an array of 6500's.  Furthermore, we had been running the SXH5
code
> with the "logging count" command element enabled on two of the four
core
> switches for 30 days (the code had actually been running for three
months+)
> 



From mtinka at globaltransit.net  Mon Sep 21 11:16:33 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 21 Sep 2009 23:16:33 +0800
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten me
	on this?
In-Reply-To: <500ffb690909210745y7b69fa12n8ab12f27352fc9fe@mail.gmail.com>
References: <027701ca3a3b$1164ca60$342e5f20$@com>
	<200909212200.35552.mtinka@globaltransit.net>
	<500ffb690909210745y7b69fa12n8ab12f27352fc9fe@mail.gmail.com>
Message-ID: <200909212316.45594.mtinka@globaltransit.net>

On Monday 21 September 2009 10:45:43 pm Steven Fischer 
wrote:

> the specific bug that caused my issue is *CSCta02715*

Many thanks, and best of luck moving forward.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090921/77afd1ba/attachment.bin>

From amsoares at netcabo.pt  Mon Sep 21 12:28:30 2009
From: amsoares at netcabo.pt (Antonio Soares)
Date: Mon, 21 Sep 2009 17:28:30 +0100
Subject: [c-nsp] 7600-ES20 L2 and L3 Multiplexing
Message-ID: <291C64EB0C1842DD897DEFED84820A94@int.convex.pt>

Hello group,

I have a ES20 interface configured with L2 services via the "service instance" command. Now i would like to add L3 services to the
same physical interface but i noticed a problem with IPv6:

7600#
7600#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
7600(config)#!
7600(config)#interface GigabitEthernet3/0/0.200100
7600(config-subif)# encapsulation dot1Q 200 second-dot1q 100
7600(config-subif)# ip address 20.20.20.254 255.255.255.0
7600(config-subif)# ipv6 address 2001:20::2/64
                       ^
% Invalid input detected at '^' marker.
 
7600(config-subif)#ipv6 ?    
% Unrecognized command
7600(config-subif)#

After removing all the service instance entries, the IPv6 command was accepted. Is this a known limitation ? I saw the same problem
with 12.2(33)SRC2 and 122-33.SRD2a.


Thanks.

Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt



From A.L.M.Buxey at lboro.ac.uk  Mon Sep 21 12:30:09 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Mon, 21 Sep 2009 17:30:09 +0100
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco
	enlighten	meon this?
In-Reply-To: <5A69C25361FED34F83ABF05F5047524505CD88A7@wally.walleyetrading.net>
References: <mailman.1.1253548800.62389.cisco-nsp@puck.nether.net>
	<5A69C25361FED34F83ABF05F5047524505CD88A7@wally.walleyetrading.net>
Message-ID: <20090921163009.GA26059@lboro.ac.uk>

Hi,

> I wanted SXI for something, I can't remember what - maybe I should have
> stayed back at SXF8. :( 

:-) SXF was, in the main, quite good. we had to move because of
feature support etc only being in the latest trains. SXI because of
longterm support (which SXH doesnt have)....usually the bugs were small
annoyances (maybe oversimplistic - but these latest issues seem to be
big big show stoppers :-( )

alan

From nsp at myzionetworks.com  Mon Sep 21 12:32:06 2009
From: nsp at myzionetworks.com (Todd)
Date: Mon, 21 Sep 2009 12:32:06 -0400
Subject: [c-nsp] Split T1's on Channelized DS3 card
Message-ID: <001d01ca3ad9$10022250$300666f0$@com>

I've got a few customers on T1's that are split for data and voice.  These
T's are currently coming in on a standard T1 serial card in a 7513 chassis.
I'm trying to move them to a channelized DS3 card.  I've got the channel
groups split and setup as needed but the T1 never comes up.  Anyone know if
this is this a limitation to the channelized DS3 card or should this
configuration work as expected?

Thanks.




From Michael.Balasko at cityofhenderson.com  Mon Sep 21 12:33:02 2009
From: Michael.Balasko at cityofhenderson.com (Michael Balasko)
Date: Mon, 21 Sep 2009 09:33:02 -0700
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten
	meon this?
In-Reply-To: <500ffb690909210745y7b69fa12n8ab12f27352fc9fe@mail.gmail.com>
References: <027701ca3a3b$1164ca60$342e5f20$@com><20090921082454.GB25187@lboro.ac.uk><500ffb690909210631n158f65ceob056bace17ce666c@mail.gmail.com><200909212200.35552.mtinka@globaltransit.net>
	<500ffb690909210745y7b69fa12n8ab12f27352fc9fe@mail.gmail.com>
Message-ID: <9AF22D15085E7D409ED5710CBC779E930BDA8D9E@COHNTCS09.ci.henderson.nv.us>

Steve, 

I have been through all that you mention myself. That being said, I have
had very good luck in requesting TAC in Mexico or Australia for late
night escalation assistance. *WARNING horrible generalization to follow*
- I have had very good luck with the skill sets found in both places.
YMMV. 


My TAC approach- When the first TAC guy tells me to send a show tech
while it and other relevant pieces of info are attached to the case, I
immediately close the case and re-open it. This way I can roast the guy
on the survey. Sadly, If it gets escalated/transferred I cannot
selectively rate each person on the case, so as a "workaround" this is
how I get my two cents in.


Mike


From petelists at templin.org  Mon Sep 21 12:42:55 2009
From: petelists at templin.org (Pete Templin)
Date: Mon, 21 Sep 2009 11:42:55 -0500
Subject: [c-nsp] Split T1's on Channelized DS3 card
In-Reply-To: <001d01ca3ad9$10022250$300666f0$@com>
References: <001d01ca3ad9$10022250$300666f0$@com>
Message-ID: <4AB7AD0F.8010103@templin.org>

Todd wrote:
> I've got a few customers on T1's that are split for data and voice.  These
> T's are currently coming in on a standard T1 serial card in a 7513 chassis.
> I'm trying to move them to a channelized DS3 card.  I've got the channel
> groups split and setup as needed but the T1 never comes up.  Anyone know if
> this is this a limitation to the channelized DS3 card or should this
> configuration work as expected?

We do TDM voice (i.e. DS0s 1-12 are for POTS lines) and data (i.e. DS0s 
13-24 are in a channel-group for Serial1/2/3/4:5) all day long.  We have 
a DACS upstream of our 7206/7507s that splits the voice and data at the 
CO, and we use Adtran CPE to handle the far end.  Nothing fancy needed 
on our routers to do this.

cont T3 X/Y/Z
  t1 A chan B tim C-D
!
int SerialX/Y/Z/A:B
  description this is a T1
  ip addr 10.10.10.10 255.255.255.252
!
ip route 10.20.30.0 255.255.255.0 sX/Y/Z/A:B
!
end

pt


From justin at justinshore.com  Mon Sep 21 12:55:28 2009
From: justin at justinshore.com (Justin Shore)
Date: Mon, 21 Sep 2009 11:55:28 -0500
Subject: [c-nsp] Comparison of T3 and T1 PAs?
Message-ID: <4AB7B000.5070703@justinshore.com>

Does anyone know of a good article, table or chart that compares the
various T3 and T1 PA options?  I've found a variety of docs but nothing 
of them giving a clear and concise list of differences between the PAs 
(features, chassis support, NPE support, etc).

PA-T3
PA-T3+
PA-MC-T3
PA-MC-T3+
PA-MC-T3-EC

PA-8T
PA-MC-8DSX1
PA-MC-8T1
PA-MCX-8TE1-M

I found this doc on the T1s which helped a little but not much.

http://www.cisco.com/en/US/docs/interfaces_modules/port_adapters/install_upgrade/multichannel_serial/multichannel-dsi.pri_install_config/3525over.html

I've found all sorts of docs on the DS3s but again nothing terribly 
concise or a clear-cut comparison between the different models.  For 
example I know that the PA-MC-T3-EC can do MLPPP in hardware but not on 
the PA-MC-T3+.

We bought the EC model for our T1 delivery service on 7200s (G2) but is 
it really needed?  A fully-loaded 7200 with PA-MC-2T3-EC modules only 
puts 12 DS3s in a chassis.  At full line-rate that's just shy of the 
throughput limit on a G1 and still half that of our G2.  Now I'm sure if 
all our DS1s were in MLPPP bundles that this would certainly add load to 
the CPU but we're 25/75 CC DS1s and MLPPP bundles at this point.  I 
could probably buy used PA-MC-T3 cards and do what I need if only I knew 
what the feature differences were.

One thing I need to know is on which T1 PAs is MLPPP supported.  I need 
to know if MPLS (core-facing) would be supported on a bundle of T1s.  I 
need to know which DS3 modules support core-facing MPLS.  I have an 
application that requires me to place a PE at a customer site to drop 
Internet and private WAN service and connect to it via T1s.  I've 
contemplated ISRs and MFT VWICs and HWICs.  I'm also looking at used 
7200s which uses T1 PAs or a M13 and a used DS3 PA.  I can come up with 
the 7200 solution far cheaper than the ISR and new MFT solution. 
Unfortunately I'm not terribly familiar with older DS1/DS3 PAs or NPEs 
or controller cards prior to the G1.

So, does anyone know of a good comparison between the assorted DS1/DS3 PAs?

Thanks
  Justin


From petelists at templin.org  Mon Sep 21 13:10:17 2009
From: petelists at templin.org (Pete Templin)
Date: Mon, 21 Sep 2009 12:10:17 -0500
Subject: [c-nsp] Comparison of T3 and T1 PAs?
In-Reply-To: <4AB7B000.5070703@justinshore.com>
References: <4AB7B000.5070703@justinshore.com>
Message-ID: <4AB7B379.7060108@templin.org>

Justin Shore wrote:
> Does anyone know of a good article, table or chart that compares the
> various T3 and T1 PA options?  I've found a variety of docs but nothing 
> of them giving a clear and concise list of differences between the PAs 
> (features, chassis support, NPE support, etc).
> 
> PA-T3
> PA-T3+
> PA-8T

These PAs, without -MC in the model, deal with their ports as a single 
interface.  In other words, if you insert a PA-8T into a 7206 in slot 6, 
I'd anticipate Serial6/0 through Serial6/7 showing up in your config.

> PA-MC-8DSX1
> PA-MC-8T1
> PA-MCX-8TE1-M
> PA-MC-T3
> PA-MC-T3+
> PA-MC-T3-EC

These PAs, with -MC in the model, are channelized ("Multi Channel"), and 
can (must?) deal with their ports as multiple channel groupings, each of 
which presents itself as a Serial interface once configured.

> I've found all sorts of docs on the DS3s but again nothing terribly 
> concise or a clear-cut comparison between the different models.  For 
> example I know that the PA-MC-T3-EC can do MLPPP in hardware but not on 
> the PA-MC-T3+.

Correct.  The PA-MC-T3+ depends on the system CPU for MLPPP.  AFAIK, the 
system CPU still handles the basic PPP duties, thereby negating some of 
the redundancy features that you'd hope/expect in a 7500.

> We bought the EC model for our T1 delivery service on 7200s (G2) but is 
> it really needed?  A fully-loaded 7200 with PA-MC-2T3-EC modules only 
> puts 12 DS3s in a chassis.  At full line-rate that's just shy of the 
> throughput limit on a G1 and still half that of our G2.  Now I'm sure if 
> all our DS1s were in MLPPP bundles that this would certainly add load to 
> the CPU but we're 25/75 CC DS1s and MLPPP bundles at this point.  I 
> could probably buy used PA-MC-T3 cards and do what I need if only I knew 
> what the feature differences were.

We converted a POP from 7507/RSP4/VIP2-50s to 7206/NPE-225, with one 
PA-MC-2T3+.  One T3 had fractional T1s on it (about 3/4 full), the other 
T3 had full T1s on it (about 3/4 full), with three MLPPP groups totaling 
about 10 T1s.  We saw CPU around 20-35%, which had me a little worried. 
  It's held steady in proportion to MLPPP traffic, so I've been OK.  I 
had an internal policy to limit 7206/7507s to no more than two 
PA-MC-2T3, for stability and config size, which should have kept the 
7206 CPU down sufficiently for us.

> One thing I need to know is on which T1 PAs is MLPPP supported.  I need 
> to know if MPLS (core-facing) would be supported on a bundle of T1s.  I 
> need to know which DS3 modules support core-facing MPLS.

MLPPP should be supported with most IOS, as long as you keep the bundle 
on a single PA.

Core-facing MPLS on MLPPP is going to be a problem.  You may want to 
search the archives for a post from Rodney Dunn on this particular 
topic.  He mentioned that it definitely wasn't supported under 
12.0(27)S, and I knew we were running it on that 12.0(27)S5.  I checked 
my routers, and found that VIP CPU on the relevant boxes was pegged at 
99% since a recent topology change, and was impacting packet forwarding 
heavily over that path.  That link was going away anyway, so we 
torpedoed it that night.

pt


From bacon at walleyesoftware.com  Mon Sep 21 13:15:52 2009
From: bacon at walleyesoftware.com (Jeff Bacon)
Date: Mon, 21 Sep 2009 12:15:52 -0500
Subject: [c-nsp] IOS for 7206VXR, SRD2a or SRC4?
Message-ID: <5A69C25361FED34F83ABF05F5047524505CD88AD@wally.walleyetrading.net>

Not to ask a dumb question, but... 

What is the point of the 12.2SR train, vs 12.4/12.4T? Besides internal
Cisco infighting over who-knows-what in the 7600/6500 split?
 


From r.nevot at gmail.com  Mon Sep 21 14:12:46 2009
From: r.nevot at gmail.com (Raul Lopez Nevot)
Date: Mon, 21 Sep 2009 20:12:46 +0200
Subject: [c-nsp] Cisco TAC issues - can someone from Cisco enlighten
	meon this?
In-Reply-To: <9AF22D15085E7D409ED5710CBC779E930BDA8D9E@COHNTCS09.ci.henderson.nv.us>
References: <027701ca3a3b$1164ca60$342e5f20$@com>
	<20090921082454.GB25187@lboro.ac.uk>
	<500ffb690909210631n158f65ceob056bace17ce666c@mail.gmail.com>
	<200909212200.35552.mtinka@globaltransit.net>
	<500ffb690909210745y7b69fa12n8ab12f27352fc9fe@mail.gmail.com>
	<9AF22D15085E7D409ED5710CBC779E930BDA8D9E@COHNTCS09.ci.henderson.nv.us>
Message-ID: <a3e64f390909211112v4c8a5489h54bf78d3f0771763@mail.gmail.com>

Oh, you are not alone!

Greg Ferro has defined it:
http://etherealmind.com/network-dictionary-tacrathon/

From graham at g-rock.net  Mon Sep 21 15:22:19 2009
From: graham at g-rock.net (Graham Wooden)
Date: Mon, 21 Sep 2009 14:22:19 -0500
Subject: [c-nsp] WIC-T1 total output drops?
Message-ID: <C6DD3C9B.A7EC%graham@g-rock.net>

Hi there,

On a recently T1 PtP deployment, I noticed that one end is getting a high
number of ?Total output drops?.  51 in the last 24 minutes.
No other errors or abnormalities on this one side, and the other side is at
0.

What could cause this? My T1 debugging skills are still in novice mode.
Is this something that I need to be concerned with or am I overly paranoid?

Currently, not a ?whole lot of? traffic is going over this link; but I did
setup the QoS for that ?just incase?.


Serial0/0 is up, line protocol is up
  Hardware is PQUICC with Fractional T1 CSU/DSU
  Internet address is nn.nn.nn.nn/30
  MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
     reliability 255/255, txload 3/255, rxload 1/255
  Encapsulation HDLC, loopback not set
  Keepalive set (10 sec)
  Last input 00:00:06, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:24:03
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 51
  Queueing strategy: Class-based queueing
  Output queue: 0/1000/64/51 (size/max total/threshold/drops)
     Conversations  0/12/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 384 kilobits/sec
  30 second input rate 6000 bits/sec, 6 packets/sec
  30 second output rate 24000 bits/sec, 6 packets/sec
     27702 packets input, 3869862 bytes, 0 no buffer
     Received 168 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     37788 packets output, 33192561 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up
 
---
 Serial0/0 

  Service-policy output: VOIP

    Class-map: VOIP (match-any)
      15111 packets, 3175756 bytes
      30 second offered rate 3000 bps, drop rate 0 bps
      Match: access-group 11
        15111 packets, 3175756 bytes
        30 second rate 3000 bps
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 50 (%)
        Bandwidth 768 (kbps) Burst 19200 (Bytes)
        (pkts matched/bytes matched) 1832/387269
        (total drops/bytes drops) 0/0

    Class-map: class-default (match-any)
      39495 packets, 42393526 bytes
      30 second offered rate 188000 bps, drop rate 0 bps
      Match: any 
      Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 256
        (total queued/total drops/no-buffer drops) 40/51/0



From chris.flav at yahoo.ca  Mon Sep 21 15:25:48 2009
From: chris.flav at yahoo.ca (chris.flav at yahoo.ca)
Date: Mon, 21 Sep 2009 19:25:48 +0000
Subject: [c-nsp] Out of order queuing
Message-ID: <201983832-1253561056-cardhu_decombobulator_blackberry.rim.net-998904832-@bda577.bisx.prod.on.blackberry>

Hello,

We have a customer with load-balanced path to us.  TCP throughput is
affected by some out-of-order packets, and we were looking for a way to
queue the interface in order to try and mitigate this.  Is it possible
to use any queueing mechanism to re-order packets received from this
customer before transmitting them, even at the cost of latency?!

I tried experimentation with CBWFQ with little to no success.  Any tips?

Thanks,

C. Flav



From justin at justinshore.com  Mon Sep 21 15:44:25 2009
From: justin at justinshore.com (Justin Shore)
Date: Mon, 21 Sep 2009 14:44:25 -0500
Subject: [c-nsp] Out of order queuing
In-Reply-To: <201983832-1253561056-cardhu_decombobulator_blackberry.rim.net-998904832-@bda577.bisx.prod.on.blackberry>
References: <201983832-1253561056-cardhu_decombobulator_blackberry.rim.net-998904832-@bda577.bisx.prod.on.blackberry>
Message-ID: <4AB7D799.4020907@justinshore.com>

chris.flav at yahoo.ca wrote:
> Hello,
> 
> We have a customer with load-balanced path to us.  TCP throughput is
> affected by some out-of-order packets, and we were looking for a way to
> queue the interface in order to try and mitigate this.  Is it possible
> to use any queueing mechanism to re-order packets received from this
> customer before transmitting them, even at the cost of latency?!
> 
> I tried experimentation with CBWFQ with little to no success.  Any tips?

Is a different load balancing algorithm possible here?  Perhaps 
flow-based load-balancing instead of packet-based would solve the 
problem.  Less throughput achieved per flow but it should balance itself 
out when you factor in all the other flows.  Plus no out-of-order packets.

Justin



From chris.flav at yahoo.ca  Mon Sep 21 15:56:44 2009
From: chris.flav at yahoo.ca (chris.flav at yahoo.ca)
Date: Mon, 21 Sep 2009 19:56:44 +0000
Subject: [c-nsp] Out of order queuing
Message-ID: <292735683-1253562912-cardhu_decombobulator_blackberry.rim.net-1484204572-@bda577.bisx.prod.on.blackberry>

>Is a different load balancing algorithm possible here?? Perhaps flow-based load-balancing instead of packet-based would solve the problem.? Less throughput>achieved per flow but it should balance itself out when you factor in all the other flows.? Plus no out-of-order packets.>>Justin


Hello,

Unfortunately the point of this load balancing is to allow more throughput per flow.? There is actually more throughput possible, however a good amount (20-30%) is not available with 2 paths, and almost no gain whatsoever is made when a third path is added.

Is there no queueing mechanism that can mitigate this that we could apply on the interface facing us?

C. Flav


From lists.james.edwards at gmail.com  Mon Sep 21 17:22:03 2009
From: lists.james.edwards at gmail.com (james edwards)
Date: Mon, 21 Sep 2009 15:22:03 -0600
Subject: [c-nsp] Help with QoS
Message-ID: <b7f636a60909211422g538bc186v739aa63a0bea39d4@mail.gmail.com>

This is on the 2811, I get this error:


I/f GigabitEthernet0/2/0 class class-default requested bandwidth 50%,
available only 25%


When applying this service policy to this interface (20 mgs commited):


interface GigabitEthernet0/2/0
 bandwidth 20000
service-policy out ALBD-SHAPE


class-map match-all STORSERV
 match access-group 110
!
!
policy-map ALBD-SHAPE
 class STORSERV
  bandwidth percent 50
 class class-default
  bandwidth percent 50
  random-detect


I am trying a allocate 50 % (10 megs) to the storserv and the rest to the
default class.


-- 
James H. Edwards
Network Systems Administrator
Judicial Information Division
jedwards at nmcourts.gov

From dale.shaw+cisco-nsp at gmail.com  Mon Sep 21 17:47:02 2009
From: dale.shaw+cisco-nsp at gmail.com (Dale Shaw)
Date: Tue, 22 Sep 2009 07:47:02 +1000
Subject: [c-nsp] Help with QoS
In-Reply-To: <b7f636a60909211422g538bc186v739aa63a0bea39d4@mail.gmail.com>
References: <b7f636a60909211422g538bc186v739aa63a0bea39d4@mail.gmail.com>
Message-ID: <3329cbb40909211447l7e84ec65q2c3916d4df10f2a4@mail.gmail.com>

Hi James,

On Tue, Sep 22, 2009 at 7:22 AM, james edwards
<lists.james.edwards at gmail.com> wrote:
> This is on the 2811, I get this error:
>
> I/f GigabitEthernet0/2/0 class class-default requested bandwidth 50%,
> available only 25%

You're getting this message because, by default, IOS enforces an
administrative limit of 75% of total interface bandwidth (as specified
with the 'bandwidth' command) for allocation to classes.

> When applying this service policy to this interface (20 mgs commited):
>
> interface GigabitEthernet0/2/0
> ?bandwidth 20000
> service-policy out ALBD-SHAPE
>
[...]
>
> I am trying a allocate 50 % (10 megs) to the storserv and the rest to the
> default class.

Try it again after putting "max-reserved-bandwidth 100" on Gi0/2/0.

cheers,
Dale

From joseph at burford.me  Mon Sep 21 17:57:53 2009
From: joseph at burford.me (Joseph Burford)
Date: Tue, 22 Sep 2009 07:27:53 +0930
Subject: [c-nsp] Help with QoS
In-Reply-To: <b7f636a60909211422g538bc186v739aa63a0bea39d4@mail.gmail.com>
References: <b7f636a60909211422g538bc186v739aa63a0bea39d4@mail.gmail.com>
Message-ID: <c295529d0909211457r7796a6fbjfd76ca0749e100a7@mail.gmail.com>

Hi James,

> I/f GigabitEthernet0/2/0 class class-default requested bandwidth 50%,
> available only 25%

> I am trying a allocate 50 % (10 megs) to the storserv and the rest to the
> default class.

By default you can only allocated up to 75% of the link bandwidth for
QOS policies, the rest is reserved for headroom.

You can use the command max-reserved-bandwidth on an interface to
change this to a higher percentage value.

Regards,

Joseph

From andy.saykao at staff.netspace.net.au  Mon Sep 21 21:40:26 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Tue, 22 Sep 2009 11:40:26 +1000
Subject: [c-nsp] Router logs going to dmesg
References: <56F211C5E3F24F47B103EA1B253822BE044AAC3C@vic-cr-ex1.staff.netspace.net.au>
	<alpine.WNT.2.00.0909211057420.2104@pckoug1.intranet.gr>
Message-ID: <56F211C5E3F24F47B103EA1B253822BE044AAC42@vic-cr-ex1.staff.netspace.net.au>

Thanks John.

Your suggestion did the trick.

Much appreciated.

Cheers.

Andy 

-----Original Message-----
From: John Kougoulos [mailto:koug at intracom.gr] 
Sent: Monday, 21 September 2009 6:03 PM
To: Andy Saykao
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Router logs going to dmesg

Hello,

somewhere at the start of syslog.conf you will see something like:
*.err                      /dev/sysmsg
*err;kern.debug		   /var/adm/messages

*.alert;kern.err	  operator
etc.

change it to something like:
*.err;local0.none	      /dev/sysmsg
*err;kern.debug;local0.none   /var/adm/messages

etc.

and then pkill -1 syslogd

Regards,
John

On Mon, 21 Sep 2009, Andy Saykao wrote:

> Hi All,
>
> I'm trying to send cisco logs to a syslog server running Solaris 9. 
> It's logging fine except that I'm seeing some logs showing up in
dmesg.
>
> Example of a dmesg outout:
>
> Sep 21 13:44:16 [172.16.9.18.224.173] 3297: Sep 21 13:44:15.981 AEST:
> %LINK-3-UPDOWN: Interface GigabitEthernet0/45, changed state to down 
> Sep 21 13:44:21 [172.16.9.18.224.173] 3298: Sep 21 13:44:20.956 AEST:
> %LINK-3-UPDOWN: Interface GigabitEthernet0/45, changed state to up Sep

> 21 13:48:38 agr1-cr-loopback-0.x.x.x 315047: Sep 21 13:48:37.756
> AEST: %SNMP-3-AUTHFAIL: Authentication failure for SNMP req from host
> 83.143.128.1
>
> I've tried changing the facility to local0.info on the cisco devices 
> but still the same thing is happening. Is there a particular facility 
> I should be using so the logs don't appear in dmesg???
>
> This was the only thing I could find on goggle about my problem but no

> real solution.
>
> http://www.velocityreviews.com/forums/t34315-which-facility-is-best-fo
> r-
> logging-to-linux-syslog.html
>
>
> This is my /etc/syslog.conf file.
>
> # Log cisco routers
> local0.info                                     /var/log/cisco.log
>
>
> And my config on the routers.
>
> logging facility local0
> logging source-interface Loopback0
> logging 210.15.210.x
>
> Thanks.
>
> Andy
>
> This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they
are addressed.
> Please notify the sender immediately by email if you have received 
> this email by mistake and delete this email from your system. 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
organisation.
> Finally, the recipient should check this email and any attachments for

> the presence of viruses. The organisation accepts no liability for any

> damage caused by any virus transmitted by this email.
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

From michael at rancid.berkeley.edu  Mon Sep 21 21:51:47 2009
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Mon, 21 Sep 2009 18:51:47 -0700
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863B3E88201C@exchange.aoihq.local>
References: <4AAFD139.4050402@west.net>
	<4AAFD6B9.4050903@forthnet.gr>	<4AAFD842.6030801@west.net>
	<4AAFDB58.4040204@rollernet.us>	<4AAFE01C.3080602@cisco.com>	<5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>	<20090918103632.GT1508@greenie.muc.de>	<DD8F8D35B252094B813ADA95905F4AFD21216127B4@ukexhcm1.lbi.local>	<20090918114057.GU1508@greenie.muc.de>
	<2C05E949E19A9146AF7BDF9D44085B863B3E88201C@exchange.aoihq.local>
Message-ID: <4AB82DB3.5080905@rancid.berkeley.edu>

On 9/18/09 5:59 AM, Eric Van Tol wrote:

> My impression is that they take their feedback from customers that
> don't use the Cisco site all that often and are caught up in the
> mythical "Web 2.0" garbage that keeps infecting the internet.

Except that, in Cisco's case, it's "Web 2.0(45a)SXB12b."  And it doesn't 
actually work.

What's amazing is that after several tries to get the stoopid thing to 
work, I still had to rename the files (with the embedded backslashes 
mentioned before).  Clearly, they didn't test on any platform other than 
Oscar Bauer's Windows XP machine.  That's such a fundamental violation 
of any interoperability standard that it's laughable.

Anyway, the reason I had to download the image I was downloading was to 
see if it actually supported the WS-6324-MM card for the 6500.  See, the 
release notes all say that all versions of 12.2(33)SXH and 12.2(33)SXI 
are supposed to support this card, but of course they don't (they were 
supposed to stop supporting the WS-6324-SM card but someone apparently 
screwed up and stopped supporting both cards).  Cisco "fixed" the 
problem so that the IOS no longer powers down the card as "unsupported." 
  It happily identifies the card and allows it to consume power, but it 
won't let you configure the interfaces, nor will it forward traffic, etc.

My general experience today makes me wonder if Cisco has any idea what 
the word "support" means anymore.

michael

From jared at puck.nether.net  Mon Sep 21 23:03:44 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 21 Sep 2009 23:03:44 -0400
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <4AB82DB3.5080905@rancid.berkeley.edu>
References: <4AAFD139.4050402@west.net>
	<4AAFD6B9.4050903@forthnet.gr>	<4AAFD842.6030801@west.net>
	<4AAFDB58.4040204@rollernet.us>	<4AAFE01C.3080602@cisco.com>	<5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>	<20090918103632.GT1508@greenie.muc.de>	<DD8F8D35B252094B813ADA95905F4AFD21216127B4@ukexhcm1.lbi.local>	<20090918114057.GU1508@greenie.muc.de>
	<2C05E949E19A9146AF7BDF9D44085B863B3E88201C@exchange.aoihq.local>
	<4AB82DB3.5080905@rancid.berkeley.edu>
Message-ID: <BAA50624-A446-46E3-B6CD-1FB0945CF8E0@puck.nether.net>


On Sep 21, 2009, at 9:51 PM, Michael Sinatra wrote:

> On 9/18/09 5:59 AM, Eric Van Tol wrote:
>
>> My impression is that they take their feedback from customers that
>> don't use the Cisco site all that often and are caught up in the
>> mythical "Web 2.0" garbage that keeps infecting the internet.
>
> Except that, in Cisco's case, it's "Web 2.0(45a)SXB12b."  And it  
> doesn't actually work.
>
> What's amazing is that after several tries to get the stoopid thing  
> to work, I still had to rename the files (with the embedded  
> backslashes mentioned before).  Clearly, they didn't test on any  
> platform other than Oscar Bauer's Windows XP machine.  That's such a  
> fundamental violation of any interoperability standard that it's  
> laughable.

I talked to Oscar, while I do agree with the image that you paint, he  
also claimed that there was testing on more than 1 platform/OS.  I  
don't know how broad this is, but you should continue to make your  
feedback well known.  You can have your SE send him an email as well  
as those in his mgmt chain if you do not feel his responses were good  
enough for your needs.

I honestly think he is going to address this issue.  I think the  
workaround process of opening a TAC case for each image you want to  
download will help keep this process at the forefront of the radar on  
the support org.

Also, if you got the Walker Survey, make sure your sales rep  
understands the impact this has on your responses.  Their bonus is  
impacted based on this response.

	- Jared

From gert at greenie.muc.de  Tue Sep 22 02:53:29 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 22 Sep 2009 08:53:29 +0200
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <BAA50624-A446-46E3-B6CD-1FB0945CF8E0@puck.nether.net>
References: <4AAFD842.6030801@west.net> <4AAFDB58.4040204@rollernet.us>
	<4AAFE01C.3080602@cisco.com>
	<5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>
	<20090918103632.GT1508@greenie.muc.de>
	<DD8F8D35B252094B813ADA95905F4AFD21216127B4@ukexhcm1.lbi.local>
	<20090918114057.GU1508@greenie.muc.de>
	<2C05E949E19A9146AF7BDF9D44085B863B3E88201C@exchange.aoihq.local>
	<4AB82DB3.5080905@rancid.berkeley.edu>
	<BAA50624-A446-46E3-B6CD-1FB0945CF8E0@puck.nether.net>
Message-ID: <20090922065329.GQ1508@greenie.muc.de>

Hi,

On Mon, Sep 21, 2009 at 11:03:44PM -0400, Jared Mauch wrote:
> Also, if you got the Walker Survey, make sure your sales rep  
> understands the impact this has on your responses.  Their bonus is  
> impacted based on this response.

Now I understand why our sales rep is changing at least once per year...

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090922/4f76a9bd/attachment.bin>

From lists at quux.de  Tue Sep 22 06:04:45 2009
From: lists at quux.de (Jens Link)
Date: Tue, 22 Sep 2009 12:04:45 +0200
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <BAA50624-A446-46E3-B6CD-1FB0945CF8E0@puck.nether.net> (Jared
	Mauch's message of "Mon\, 21 Sep 2009 23\:03\:44 -0400")
References: <4AAFD139.4050402@west.net> <4AAFD6B9.4050903@forthnet.gr>
	<4AAFD842.6030801@west.net> <4AAFDB58.4040204@rollernet.us>
	<4AAFE01C.3080602@cisco.com>
	<5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>
	<20090918103632.GT1508@greenie.muc.de>
	<DD8F8D35B252094B813ADA95905F4AFD21216127B4@ukexhcm1.lbi.local>
	<20090918114057.GU1508@greenie.muc.de>
	<2C05E949E19A9146AF7BDF9D44085B863B3E88201C@exchange.aoihq.local>
	<4AB82DB3.5080905@rancid.berkeley.edu>
	<BAA50624-A446-46E3-B6CD-1FB0945CF8E0@puck.nether.net>
Message-ID: <87y6o747nm.fsf@laphroiag.quux.de>

Jared Mauch <jared at puck.nether.net> writes:

> I talked to Oscar, while I do agree with the image that you paint, he
> also claimed that there was testing on more than 1 platform/OS. 

Well Windows 2000, XP, Vista and 7 are different operating systems. And
testing isn't any good if you ignore the results. ;-)

On the bright side: Download worked for me using Debian Testing +
Firefox. 

cheers,

Jens
-- 
-------------------------------------------------------------------------
| Foelderichstr. 40  | 13595 Berlin, Germany | +49-151-18721264         |
| http://www.quux.de | http://blog.quux.de   | jabber: jenslink at guug.de |
-------------------------------------------------------------------------

From bandwidth.user at gmail.com  Tue Sep 22 06:52:53 2009
From: bandwidth.user at gmail.com (roy)
Date: Tue, 22 Sep 2009 18:52:53 +0800
Subject: [c-nsp] 720x VXR -12V Sensor
Message-ID: <4AB8AC85.4080003@gmail.com>

Does anyone know which IC is being used by the 720x VXR router for 
monitoring the voltage readings (specially the one for -12V)?

I've looked around and seems the DS1620 on I/O card is only for 
temperature. I could be wrong though.

Would appreciate if anyone can point me into the right docs. Trying to 
troubleshoot an internal -12V issue which shuts down my 7206VXR upon 
reaching the threshold within 5 minutes of power-up.

This happens on C7206VXR chassis, NPE-400, I/O-2FE/E controller. I have 
only been looking into the I/O controller. All tray fans working; input 
voltage good and clean on either/both PSU's. Inlet/outlet temps within 
range.

Thanks,

roy

From rnbrady at gmail.com  Tue Sep 22 07:52:30 2009
From: rnbrady at gmail.com (Richard Brady)
Date: Tue, 22 Sep 2009 12:52:30 +0100
Subject: [c-nsp]  HWIC-1ADSL-M
Message-ID: <4d6de31b0909220452m14ad62e7q8cb3d7fbd077c849@mail.gmail.com>

Hi Alex

This is an interesting one. I've used 877-M and 1801-M with Be/O2 and
don't have a problem on Annex M.

On Friday I tried both with a Tiscali (via Griffin) service and
couldn't get it to sync at Annex M. When they re-graded it to remove
the Annex M it suddenly synced, but now we are seeing pretty bad QoS,
mostly packet loss. Doesn't seem to be line (SNR) or bandwidth
related, but there is significant error correction activity on the
downstream link which I find strange.

I have heard rumours about Cisco kit not liking the Tiscali DSLAMs but
can't find anything to back this up.

Richard


> On Thu Sep 03, 2009 at 07:16:27PM +0100, Alex Pimperton wrote:
> > Reading through the specs for the above card Cisco mentions not
> supporting
> > "UK Mask".
> >
> > Does this mean the card doesn't work for ADSL-M (Seemingly often
> branded as
> > SDSL-M) in the UK?
>
> ADSL and SDSL are two very different things. HWIC-1ADSL-M will do
> ADSL2+, but
> probably not SDSL.

I'm aware that it's ADSL 2+ underneath but some providers (Spitfire,
Nildram) are marketing their ADSL Annex-M products as "SDSL (M)", presumably
because of the symmetrical upload/download, and the fact that it sounds like
SDSL, which business are already familiar with.

>
> > We're looking at getting some SDSL-M circuits to see what they're
> like, from
> > Spitfire and Nildram (Tiscali), anybody using either HWIC-1ADSL-M or
> C877-M
> > with those providers Annex M services?
>
> We sell ADSL2+ services in the UK using Be/O2 LLU tails, and they have
> "approved" bother the HWIC-1ADSL-M and the C877-M for their service.
> I'm using
> a C877-M right now.

Thanks Simon, I saw mention of the C877-M on the BE UserGroup website but no
specific mention of Annex-M products on the (colourful) BE website.

Anybody else using Cisco kit at the end of an Annex-M tail from another
provider?

Cheers,

Alex

From asnoka at gmail.com  Tue Sep 22 09:49:25 2009
From: asnoka at gmail.com (asnoka zhung)
Date: Tue, 22 Sep 2009 21:49:25 +0800
Subject: [c-nsp] Doubt about dynamic MS-PW (MultiSegment-PseudoWire)
Message-ID: <a910c8ba0909220649p11dd10b8s8703d5fd0ea8649e@mail.gmail.com>

  Recently I have an opportunity to study the dynamic MS-PW draft,can anyone
tell me
whether it is supported on cisco 7200 platform?
  Thank you.

-- 
Learning Linux:)
---------------------------------------------------
Make Everyday Counts!

From mtinka at globaltransit.net  Tue Sep 22 03:46:56 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Tue, 22 Sep 2009 15:46:56 +0800
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <20090922065329.GQ1508@greenie.muc.de>
References: <4AAFD842.6030801@west.net>
	<BAA50624-A446-46E3-B6CD-1FB0945CF8E0@puck.nether.net>
	<20090922065329.GQ1508@greenie.muc.de>
Message-ID: <200909221547.03562.mtinka@globaltransit.net>

On Tuesday 22 September 2009 02:53:29 pm Gert Doering wrote:

> Now I understand why our sales rep is changing at least
> once per year...

Oh yes - if your Sales rep. doesn't meet their quota (with 
you), they will, very likely, be rotated at the end of the 
fiscal year.

I've always been fascinated by this, as it's a very results-
oriented system (which, in all fairness, I suppose I can 
appreciate), i.e., if they can't up-sell you, they may not 
be doing their job.

However, they may be doing other things that you find 
useful, e.g., co-ordinating your TAC case when all else 
fails, getting you that RMA in record time, ensuring that 
feature is incorporated into the code base even when the 
DE's are reluctant, sending you off to their workshops and 
conferences, engaging you as part of their R&D, including 
you in that PoC for the newly released kit, e.t.c.

But I guess the bottom line is, if they haven't up-sold you, 
they are out. What's worse is that you may not have a need 
to make a new purchase in a single year, perhaps because 
you've laced your entire network with CRS-1's, and it's 
going to be years before you need to buy another unit, line 
card, e.t.c.

Results-oriented - I think they may need to consider more 
than that. Re-bonding is not easy... but that's just me.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090922/2e25eebb/attachment.bin>

From mawhi at vestas.com  Tue Sep 22 09:59:55 2009
From: mawhi at vestas.com (Matthew White)
Date: Tue, 22 Sep 2009 06:59:55 -0700
Subject: [c-nsp] 720x VXR -12V Sensor
In-Reply-To: <4AB8AC85.4080003@gmail.com>
References: <4AB8AC85.4080003@gmail.com>
Message-ID: <E222D1E6A503BD4B815A3B6FCC50311B76562EA97D@USPDXEXC001.vestas.net>

Roy,

I encountered a similar issue with a 7204VXR + I/O-2FE/E + NPE-225.

I worked with TAC and started by replacing both power supplies; no good. This router was due for an NPE-G1 upgrade so I installed the replacement and kept the I/O controller installed; no good. I finally pulled out the I/O controller and that solved the problem.

-mtw
________________________________________
From: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net] On Behalf Of roy [bandwidth.user at gmail.com]
Sent: Tuesday, September 22, 2009 03:52
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] 720x VXR -12V Sensor

Does anyone know which IC is being used by the 720x VXR router for
monitoring the voltage readings (specially the one for -12V)?

I've looked around and seems the DS1620 on I/O card is only for
temperature. I could be wrong though.

Would appreciate if anyone can point me into the right docs. Trying to
troubleshoot an internal -12V issue which shuts down my 7206VXR upon
reaching the threshold within 5 minutes of power-up.

This happens on C7206VXR chassis, NPE-400, I/O-2FE/E controller. I have
only been looking into the I/O controller. All tray fans working; input
voltage good and clean on either/both PSU's. Inlet/outlet temps within
range.

Thanks,

roy
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From caesar at starkreality.com  Tue Sep 22 10:46:17 2009
From: caesar at starkreality.com (William S. Duncanson)
Date: Tue, 22 Sep 2009 09:46:17 -0500
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <200909221547.03562.mtinka@globaltransit.net>
References: <4AAFD842.6030801@west.net>	<BAA50624-A446-46E3-B6CD-1FB0945CF8E0@puck.nether.net>	<20090922065329.GQ1508@greenie.muc.de>
	<200909221547.03562.mtinka@globaltransit.net>
Message-ID: <000601ca3b93$7c237410$746a5c30$@com>

I specifically mentioned the musical sales rep problem as a problem in the
survey.  We'll see if they listen.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mark Tinka
Sent: Tuesday, September 22, 2009 2:47 AM
To: cisco-nsp at puck.nether.net
Cc: Gert Doering; Jared Mauch
Subject: Re: [c-nsp] "Enhanced" download procedure

On Tuesday 22 September 2009 02:53:29 pm Gert Doering wrote:

> Now I understand why our sales rep is changing at least once per 
> year...

Oh yes - if your Sales rep. doesn't meet their quota (with you), they will,
very likely, be rotated at the end of the fiscal year.

I've always been fascinated by this, as it's a very results- oriented system
(which, in all fairness, I suppose I can appreciate), i.e., if they can't
up-sell you, they may not be doing their job.

However, they may be doing other things that you find useful, e.g.,
co-ordinating your TAC case when all else fails, getting you that RMA in
record time, ensuring that feature is incorporated into the code base even
when the DE's are reluctant, sending you off to their workshops and
conferences, engaging you as part of their R&D, including you in that PoC
for the newly released kit, e.t.c.

But I guess the bottom line is, if they haven't up-sold you, they are out.
What's worse is that you may not have a need to make a new purchase in a
single year, perhaps because you've laced your entire network with CRS-1's,
and it's going to be years before you need to buy another unit, line card,
e.t.c.

Results-oriented - I think they may need to consider more than that.
Re-bonding is not easy... but that's just me.

Cheers,

Mark.


From amsoares at netcabo.pt  Tue Sep 22 11:13:12 2009
From: amsoares at netcabo.pt (Antonio Soares)
Date: Tue, 22 Sep 2009 16:13:12 +0100
Subject: [c-nsp] 7600-ES20 L2 and L3 Multiplexing
In-Reply-To: <291C64EB0C1842DD897DEFED84820A94@int.convex.pt>
References: <291C64EB0C1842DD897DEFED84820A94@int.convex.pt>
Message-ID: <1495C1CED4CF4D488DEC7D104491205C@int.convex.pt>

Hello group,

I received some off-line help and now i have a workaround:

+++++++++++++++++++++++++
 !
 service instance 200 ethernet
  encapsulation dot1q 200 second-dot1q 100
  rewrite ingress tag pop 2 symmetric
  bridge-domain 200
 !
!
interface Vlan200
 ip address 20.20.20.254 255.255.255.0
 ipv6 address 2001:20::2/64
!
+++++++++++++++++++++++++

Now there is a document about the ES20 that says the following:

"Flexible QinQ Mapping and Service Awareness on 7600-ESM-2X10GE and 7600-ESM-20X1GE is supported only through Ethernet Virtual
Connection Services (EVCS) service instances."

"The Flexible QinQ Mapping and Service Awareness on 7600-ESM-2X10GE and 7600-ESM-20X1GE feature allows service providers to offer
triple-play services, residential internet access from a DSLAM, and business Layer 2 and Layer 3 VPN by providing for termination of
double-tagged dot1q frames onto a Layer 3 subinterface at the access node."

Source:

http://www.cisco.com/en/US/products/hw/routers/ps368/products_configuration_guide_chapter09186a00807f3f97.html#wp1433597


I still do not understand if L3 sub-interfaces are supported or not and if they are, why IPv6 commands are not accepted.


Thanks.

Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Antonio Soares
Sent: segunda-feira, 21 de Setembro de 2009 17:29
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] 7600-ES20 L2 and L3 Multiplexing

Hello group,

I have a ES20 interface configured with L2 services via the "service instance" command. Now i would like to add L3 services to the
same physical interface but i noticed a problem with IPv6:

7600#
7600#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
7600(config)#!
7600(config)#interface GigabitEthernet3/0/0.200100
7600(config-subif)# encapsulation dot1Q 200 second-dot1q 100
7600(config-subif)# ip address 20.20.20.254 255.255.255.0
7600(config-subif)# ipv6 address 2001:20::2/64
                       ^
% Invalid input detected at '^' marker.
 
7600(config-subif)#ipv6 ?    
% Unrecognized command
7600(config-subif)#

After removing all the service instance entries, the IPv6 command was accepted. Is this a known limitation ? I saw the same problem
with 12.2(33)SRC2 and 122-33.SRD2a.


Thanks.

Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



From bduross at learningcaregroup.com  Tue Sep 22 12:18:36 2009
From: bduross at learningcaregroup.com (Brian DuRoss)
Date: Tue, 22 Sep 2009 11:18:36 -0500
Subject: [c-nsp] 720x VXR -12V Sensor
In-Reply-To: <4AB8AC85.4080003@gmail.com>
References: <4AB8AC85.4080003@gmail.com>
Message-ID: <C72A59B7ABF4B344A6AF56446F57BCAD05507539B8@LCGEXOAK1.cttlc.com>

> Does anyone know which IC is being used by the 720x VXR router for 
> monitoring the voltage readings (specially the one for -12V)?

> I've looked around and seems the DS1620 on I/O card is only for 
> temperature. I could be wrong though.


Roy, 

It looks like the TL7705BC or TL7702BC are the components you are looking for.

These appear to be designed to monitor voltages from 0-18V. 

http://pdf1.alldatasheet.com/datasheet-pdf/view/177129/TI/TL7705BC.html

http://pdf1.alldatasheet.com/datasheet-pdf/view/177128/TI/TL7702BC.html

They are labeled as U33 and I believe U32 on this card. (The U32 is not clearly readable on the pcb). 

These are located above the SIMM slot on the IO card. 

http://www.bsd.am/IMG_4312.JPG (warning, hi-res)

HTH, 

B



From drew.weaver at thenap.com  Tue Sep 22 14:37:41 2009
From: drew.weaver at thenap.com (Drew Weaver)
Date: Tue, 22 Sep 2009 14:37:41 -0400
Subject: [c-nsp] 6500 - stateful failover, reason?
Message-ID: <F3318834F1F89D46857972DD4B411D7001316539FA@EXCHANGE.thenap.com>

Is there any way to get more information about what caused a fail-over between two supervisors in a 6500?

All I can appear to get is "Active crashed." from show redundancy switchover and my syslog doesn't have any information either.

Also, is it normal that during switchover you will lose protocols (OSPF) and that you will see messages like these in the log?

Sep 22 08:41:17.651 EDT: %C6KPWR-SP-4-PSOK: power supply 1 turned on.
Sep 22 08:41:17.699 EDT: %C6KPWR-SP-4-PSOK: power supply 2 turned on.

The log messages sort of confuse me because show version indicates:

uptime is 10 weeks, 4 days, 1 hour, 35 minutes

So it's been up 10 weeks but the power supplies were just turned on < 12 hours ago? I assume that is just random log-spew from the hot-supervisor taking over, though?

-Drew


From avayner at cisco.com  Tue Sep 22 15:06:07 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Tue, 22 Sep 2009 21:06:07 +0200
Subject: [c-nsp] 6500 - stateful failover, reason?
In-Reply-To: <F3318834F1F89D46857972DD4B411D7001316539FA@EXCHANGE.thenap.com>
References: <F3318834F1F89D46857972DD4B411D7001316539FA@EXCHANGE.thenap.com>
Message-ID: <FDD1CDB3FB499E4087CC7670BBCA22C65160EA@XMB-AMS-101.cisco.com>

Drew,

You should have a crashinfo file on the used-to-be-primary SUP
bootflash.
The right thing would be to open a TAC case, and give the engineer the
crashinfo file and the show tech for the device.

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Drew Weaver
Sent: Tuesday, September 22, 2009 21:38
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] 6500 - stateful failover, reason?

Is there any way to get more information about what caused a fail-over
between two supervisors in a 6500?

All I can appear to get is "Active crashed." from show redundancy
switchover and my syslog doesn't have any information either.

Also, is it normal that during switchover you will lose protocols (OSPF)
and that you will see messages like these in the log?

Sep 22 08:41:17.651 EDT: %C6KPWR-SP-4-PSOK: power supply 1 turned on.
Sep 22 08:41:17.699 EDT: %C6KPWR-SP-4-PSOK: power supply 2 turned on.

The log messages sort of confuse me because show version indicates:

uptime is 10 weeks, 4 days, 1 hour, 35 minutes

So it's been up 10 weeks but the power supplies were just turned on < 12
hours ago? I assume that is just random log-spew from the hot-supervisor
taking over, though?

-Drew

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From MatlockK at exempla.org  Tue Sep 22 15:06:07 2009
From: MatlockK at exempla.org (Matlock, Kenneth L)
Date: Tue, 22 Sep 2009 13:06:07 -0600
Subject: [c-nsp] 6500 - stateful failover, reason?
In-Reply-To: <F3318834F1F89D46857972DD4B411D7001316539FA@EXCHANGE.thenap.com>
References: <F3318834F1F89D46857972DD4B411D7001316539FA@EXCHANGE.thenap.com>
Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7065D3AAA@LMC-MAIL2.exempla.org>

Those log messages are spurious. 

When a supervisor comes online a lot of things are in an 'unknown' state
by the backup (soon to be primary) supervisor. When it initializes as
the Active, it checks the status of everything such as power supplies.
What you're seeing is just the supervisor 'finding' all the gear it's
now responsible for, and marking the current status.

A 'show ver' will show you three things. 

"CAT6509SJHSS1 uptime is 1 year, 33 weeks, 2 days, 23 hours, 50 minutes"

Shows that the chassis has had at least 1 active supervisor for 1 year,
33 week.

"Time since CAT6509SJHSS1 switched to active is 2 weeks, 6 days, 9
hours, 40 minutes"

That shows the current supervisor has been the active for 2 weeks, 6
days. 

"System returned to ROM by Stateful Switchover (SP by power on)"

That shows the reason for the last switchover (in this case we had to
switch to the standby sup because of a nasty memory leak, caused by...
'show run'.

Ken Matlock
Network Analyst
Exempla Healthcare
(303) 467-4671
matlockk at exempla.org


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Drew Weaver
Sent: Tuesday, September 22, 2009 12:38 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] 6500 - stateful failover, reason?

Is there any way to get more information about what caused a fail-over
between two supervisors in a 6500?

All I can appear to get is "Active crashed." from show redundancy
switchover and my syslog doesn't have any information either.

Also, is it normal that during switchover you will lose protocols (OSPF)
and that you will see messages like these in the log?

Sep 22 08:41:17.651 EDT: %C6KPWR-SP-4-PSOK: power supply 1 turned on.
Sep 22 08:41:17.699 EDT: %C6KPWR-SP-4-PSOK: power supply 2 turned on.

The log messages sort of confuse me because show version indicates:

uptime is 10 weeks, 4 days, 1 hour, 35 minutes

So it's been up 10 weeks but the power supplies were just turned on < 12
hours ago? I assume that is just random log-spew from the hot-supervisor
taking over, though?

-Drew

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From nicotine at warningg.com  Tue Sep 22 15:06:33 2009
From: nicotine at warningg.com (Brandon Ewing)
Date: Tue, 22 Sep 2009 14:06:33 -0500
Subject: [c-nsp] 6500 - stateful failover, reason?
In-Reply-To: <F3318834F1F89D46857972DD4B411D7001316539FA@EXCHANGE.thenap.com>
References: <F3318834F1F89D46857972DD4B411D7001316539FA@EXCHANGE.thenap.com>
Message-ID: <20090922190633.GB3633@radiological.warningg.com>

On Tue, Sep 22, 2009 at 02:37:41PM -0400, Drew Weaver wrote:
> Is there any way to get more information about what caused a fail-over between two supervisors in a 6500?
> 
> All I can appear to get is "Active crashed." from show redundancy switchover and my syslog doesn't have any information either.

If it actually crashed, you may want to investigate whether a crashinfo file
was left behind.

> 
> Also, is it normal that during switchover you will lose protocols (OSPF) and that you will see messages like these in the log?
> 

This is normal -- the new processor has to rebuild all routing protocols
when it comes online from RPR or RPR+ mode.  Even with SSO mode, if NSF is
not configured with all peers on all protocols, the sessions are broken down
and rebuilt.

> Sep 22 08:41:17.651 EDT: %C6KPWR-SP-4-PSOK: power supply 1 turned on.
> Sep 22 08:41:17.699 EDT: %C6KPWR-SP-4-PSOK: power supply 2 turned on.
> 

This is normal, as part of the standby supervisor finishing initialization

> The log messages sort of confuse me because show version indicates:
> 
> uptime is 10 weeks, 4 days, 1 hour, 35 minutes
> 
> So it's been up 10 weeks but the power supplies were just turned on < 12 hours ago? I assume that is just random log-spew from the hot-supervisor taking over, though?

For more information about uptime for given processors, try 
show redundancy -- it should give total chassis uptime, last switchover
time, number of switchovers, and time on active processor.

> 
> -Drew
> 

-- 
Brandon Ewing                                        (nicotine at warningg.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090922/01e16e84/attachment.bin>

From nicotine at warningg.com  Tue Sep 22 16:25:14 2009
From: nicotine at warningg.com (Brandon Ewing)
Date: Tue, 22 Sep 2009 15:25:14 -0500
Subject: [c-nsp] 6500 - stateful failover, reason?
In-Reply-To: <6069A203FD01884885C037F81DD750801722C55038@wsc-mail-01.intra.nwresd.k12.or.us>
References: <F3318834F1F89D46857972DD4B411D7001316539FA@EXCHANGE.thenap.com>
	<20090922190633.GB3633@radiological.warningg.com>
	<6069A203FD01884885C037F81DD750801722C55038@wsc-mail-01.intra.nwresd.k12.or.us>
Message-ID: <20090922202514.GD3633@radiological.warningg.com>

On Tue, Sep 22, 2009 at 01:07:47PM -0700, Bill Blackford wrote:
> <snip>
> This is normal -- the new processor has to rebuild all routing protocols when it comes online from RPR or RPR+ mode.  Even with SSO mode, if NSF is not configured with all peers on all protocols, the sessions are broken down and rebuilt.
> </snip>
> 
> I recently had event very much like this. In my case, even SSO/NSF dropped some adjacencies during this switchover.
> 
> -b
> 

Did you confirm that NSF (Graceful restart, etc) has been negotiated with
all adjacencies, and that all adjacent routers are NSF-aware?  

Also, there is an upper bound to the time alloted to
perform the switchover, and the new RP has to signal an NSF event prior to
current hold/dead/etc timers expiring -- if you have your OSPF timer set to
1/3, and it takes more than 3 seconds for the standby RP to see the failure,
take over, and send the NSF message, the adjacency will already have been
dropped.

-- 
Brandon Ewing                                        (nicotine at warningg.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090922/036ae784/attachment.bin>

From BBlackford at nwresd.k12.or.us  Tue Sep 22 16:07:47 2009
From: BBlackford at nwresd.k12.or.us (Bill Blackford)
Date: Tue, 22 Sep 2009 13:07:47 -0700
Subject: [c-nsp] 6500 - stateful failover, reason?
In-Reply-To: <20090922190633.GB3633@radiological.warningg.com>
References: <F3318834F1F89D46857972DD4B411D7001316539FA@EXCHANGE.thenap.com>
	<20090922190633.GB3633@radiological.warningg.com>
Message-ID: <6069A203FD01884885C037F81DD750801722C55038@wsc-mail-01.intra.nwresd.k12.or.us>

<snip>
This is normal -- the new processor has to rebuild all routing protocols when it comes online from RPR or RPR+ mode.  Even with SSO mode, if NSF is not configured with all peers on all protocols, the sessions are broken down and rebuilt.
</snip>

I recently had event very much like this. In my case, even SSO/NSF dropped some adjacencies during this switchover.

-b


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Brandon Ewing
Sent: Tuesday, September 22, 2009 12:07 PM
To: Drew Weaver
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] 6500 - stateful failover, reason?

On Tue, Sep 22, 2009 at 02:37:41PM -0400, Drew Weaver wrote:
> Is there any way to get more information about what caused a fail-over between two supervisors in a 6500?
> 
> All I can appear to get is "Active crashed." from show redundancy switchover and my syslog doesn't have any information either.

If it actually crashed, you may want to investigate whether a crashinfo file was left behind.

> 
> Also, is it normal that during switchover you will lose protocols (OSPF) and that you will see messages like these in the log?
> 

This is normal -- the new processor has to rebuild all routing protocols when it comes online from RPR or RPR+ mode.  Even with SSO mode, if NSF is not configured with all peers on all protocols, the sessions are broken down and rebuilt.

> Sep 22 08:41:17.651 EDT: %C6KPWR-SP-4-PSOK: power supply 1 turned on.
> Sep 22 08:41:17.699 EDT: %C6KPWR-SP-4-PSOK: power supply 2 turned on.
> 

This is normal, as part of the standby supervisor finishing initialization

> The log messages sort of confuse me because show version indicates:
> 
> uptime is 10 weeks, 4 days, 1 hour, 35 minutes
> 
> So it's been up 10 weeks but the power supplies were just turned on < 12 hours ago? I assume that is just random log-spew from the hot-supervisor taking over, though?

For more information about uptime for given processors, try show redundancy -- it should give total chassis uptime, last switchover time, number of switchovers, and time on active processor.

> 
> -Drew
> 

-- 
Brandon Ewing                                        (nicotine at warningg.com)

From eng_mssk at hotmail.com  Tue Sep 22 18:01:50 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Wed, 23 Sep 2009 01:01:50 +0300
Subject: [c-nsp] Cisco SCE OIDs
Message-ID: <BLU102-W26A58AB11ADE9692C4D0F6FADC0@phx.gbl>


hey all 
i have cisco sce with the below version

System version: Version 3.5.0 Build 407
Build time: Dec 22 2008, 18:28:53 (Change-list 414717)
Software version is: Version 3.5.0 Build 407
Cryptography class: K9
Hardware information is:

---------------------
Firmware
---------------------
kernel      : [kernel] 2.0.0/6 (inactive: [kernel] 1.1.0/8)
u-boot      : [uboot] 1.2.0/4 (field: [uboot] 0.8.1/18)
select      : [ubs-cf1] 1.1.0/8 (secondary: [ubs-cf1] 1.1.0/8)

Platform: SCE8000 - 2x10GBE
Management agent interface version: SCE Agent 3.5.0 Build 469
Software package file: Not available

i am trying to graph some parameters such as the concurrent sessions and per package download



[failsafe at CORE ~]$ snmpwalk -v2c -c  community x.x.x.x
.1.3.6.1.4.1.5655.4.1.8.1.1.9.1

SNMPv2-SMI::enterprises.5655.4.1.8.1.1.9.1 = No Such Object
available on this agent at this OID


any ideas?

thanks

_________________________________________________________________
With Windows Live, you can organize, edit, and share your photos.
http://www.microsoft.com/middleeast/windows/windowslive/products/photo-gallery-edit.aspx

From networkjedi at geekwhore.net  Tue Sep 22 19:07:35 2009
From: networkjedi at geekwhore.net (Nick Colton)
Date: Tue, 22 Sep 2009 17:07:35 -0600
Subject: [c-nsp] Cisco 7600 vs ASR 9000
Message-ID: <497ac88a0909221607q2705f92cyba2fd714da824742@mail.gmail.com>

I work for a small CLEC, we have been doing FTTP for 5 years now but are
getting ready to update our core network and introduce IPTV services.  Cisco
has been recommending the Cisco 7600 as our core router.  My concern is that
cisco told us that in the event of an RSP fail over the 7600 could take up
to 30 seconds to begin routing packets again, this seems wrong to me since
my old Extreme Networks BD 6808 can do fail overs and rebuild route tables
in under 5 seconds but??  More recently I have been reading up on the ASR
9000 however and it appears that it would be better sized for our company
than the 7600.  A few questions I have for the group.
1.  Has anyone used the ASR 9000 in place of a Cisco 7600?

2.  Is the ASR 9000 Carrier ready?  Meaning 5x9's of availability, few
component failures, solid software...etc

3.  Has anyone had issues where it took the 7600 30 seconds to start routing
again after an RSP fail over?

Thanks,

Nick

From bandwidth.user at gmail.com  Tue Sep 22 23:10:22 2009
From: bandwidth.user at gmail.com (roy)
Date: Wed, 23 Sep 2009 11:10:22 +0800
Subject: [c-nsp] 720x VXR -12V Sensor
In-Reply-To: <E222D1E6A503BD4B815A3B6FCC50311B76562EA97D@USPDXEXC001.vestas.net>
References: <4AB8AC85.4080003@gmail.com>
	<E222D1E6A503BD4B815A3B6FCC50311B76562EA97D@USPDXEXC001.vestas.net>
Message-ID: <4AB9919E.1090405@gmail.com>

Thanks Matt and Brian.

This indeed seem to be an I/O controller issue (although the CCO docs 
say the sensors are on the PSU and the engine was supposed to process 
them). I've tried swapping I/O controllers keeping the rest of the 
hardware configuration intact; router up and running for more than 12hrs.

Might need to track down what's giving an increase in resistance which 
results to overshooting the -12V thresholds.

Regards,

Roy

From mawhi at vestas.com  Tue Sep 22 17:07:28 2009
From: mawhi at vestas.com (Matthew White)
Date: Tue, 22 Sep 2009 14:07:28 -0700
Subject: [c-nsp] NBAR + QoS - policing kills class-default traffic
Message-ID: <E222D1E6A503BD4B815A3B6FCC50311B76561518D5@USPDXEXC001.vestas.net>

Greetings,

I've got the following kit:

  Cisco 7204VXR (NPE-G1) processor
  Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 12.4(24)T1

and the following NBAR + QoS config:

class-map match-any HULU
 match protocol http host "t2.hulu.com"
 match protocol http host "t.hulu.com"
 match protocol http host "hulu.com"
class-map match-any YOUTUBE
 match protocol http host "youtube.com"
class-map match-all PANDORA
 match access-group name PANDORA_SERVERS
class-map match-any WEB_ENTERTAINMENT
 match class-map PANDORA
 match class-map HULU
 match class-map YOUTUBE

policy-map LIMIT_INTERNET_TRAFFIC
 class WEB_ENTERTAINMENT
    police 8000 conform-action transmit  exceed-action drop

interface GigabitEthernet0/1
 ip address x.x.x.x 255.255.255.192
 ip access-group 100 in
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nbar protocol-discovery
 no ip mroute-cache
 duplex full
 speed 100
 media-type rj45
 no negotiation auto
 service-policy output LIMIT_INTERNET_TRAFFIC

The policy polices HULU and PANDORA, counters don't increment for YOUTUBE (and doesn't get policed) and after 3 or 4 minutes ALL web traffic is policed. Has anyone seen this behavior before?

Yours Sincerely,

Matthew White
Sr. Network Engineer
Group IT, Operations, Network

Vestas Wind Systems A/S
T: +1 503 327 2320
M: +1 503 927 5728
mawhi at vestas.com

Company reg. name: Vestas Wind Systems A/S
This e-mail is subject  to our e-mail disclaimer statement.
Please refer to www.vestas.com/legal/notice
If you have received this e-mail in error please contact the sender.



From hank at efes.iucc.ac.il  Wed Sep 23 01:47:32 2009
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Wed, 23 Sep 2009 08:47:32 +0300 (IDT)
Subject: [c-nsp] Limiting b/w per IP?
Message-ID: <Pine.LNX.4.64.0909230842500.31695@efes.iucc.ac.il>

I haven't followed all the new bells and whistles in IOS so maybe 
something new is there that can handle this age old problem for me.

I want to be able to rate limit all IPs so that no single IP on an 
interface can eat more than say 20% of the available b/w (inbound and 
outbound).  I do not want to define every single IP of the segment in an 
ACL but can if the solution is clean.  Not interested in protocol 
rate-control - just IP b/w.

Cisco snippets or URLs welcome.

Thanks,
Hank

From avayner at cisco.com  Wed Sep 23 02:32:19 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Wed, 23 Sep 2009 08:32:19 +0200
Subject: [c-nsp] Limiting b/w per IP?
In-Reply-To: <Pine.LNX.4.64.0909230842500.31695@efes.iucc.ac.il>
References: <Pine.LNX.4.64.0909230842500.31695@efes.iucc.ac.il>
Message-ID: <FDD1CDB3FB499E4087CC7670BBCA22C6516156@XMB-AMS-101.cisco.com>

Hank,

This is available on the 6500/7600 through microflow policers:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/con
figuration/guide/qos.html#wp1571584

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Hank Nussbacher
Sent: Wednesday, September 23, 2009 08:48
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Limiting b/w per IP?

I haven't followed all the new bells and whistles in IOS so maybe 
something new is there that can handle this age old problem for me.

I want to be able to rate limit all IPs so that no single IP on an 
interface can eat more than say 20% of the available b/w (inbound and 
outbound).  I do not want to define every single IP of the segment in an

ACL but can if the solution is clean.  Not interested in protocol 
rate-control - just IP b/w.

Cisco snippets or URLs welcome.

Thanks,
Hank
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From hank at efes.iucc.ac.il  Wed Sep 23 02:56:51 2009
From: hank at efes.iucc.ac.il (hank at efes.iucc.ac.il)
Date: Wed, 23 Sep 2009 09:56:51 +0300 (IDT)
Subject: [c-nsp] Limiting b/w per IP?
In-Reply-To: <FDD1CDB3FB499E4087CC7670BBCA22C6516156@XMB-AMS-101.cisco.com>
References: <Pine.LNX.4.64.0909230842500.31695@efes.iucc.ac.il>
	<FDD1CDB3FB499E4087CC7670BBCA22C6516156@XMB-AMS-101.cisco.com>
Message-ID: <12773.79.176.132.43.1253689011.squirrel@email.iucc.ac.il>

> Hank,
>
> This is available on the 6500/7600 through microflow policers:
> http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/con
> figuration/guide/qos.html#wp1571584

Did I fail to mention that the router is much smaller? :-)

-Hank

>
> Arie
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Hank Nussbacher
> Sent: Wednesday, September 23, 2009 08:48
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Limiting b/w per IP?
>
> I haven't followed all the new bells and whistles in IOS so maybe
> something new is there that can handle this age old problem for me.
>
> I want to be able to rate limit all IPs so that no single IP on an
> interface can eat more than say 20% of the available b/w (inbound and
> outbound).  I do not want to define every single IP of the segment in an
>
> ACL but can if the solution is clean.  Not interested in protocol
> rate-control - just IP b/w.
>
> Cisco snippets or URLs welcome.
>
> Thanks,
> Hank
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


From dean at eatworms.org.uk  Wed Sep 23 03:28:34 2009
From: dean at eatworms.org.uk (Dean Smith)
Date: Wed, 23 Sep 2009 08:28:34 +0100
Subject: [c-nsp] Cisco 7600 vs ASR 9000
References: <497ac88a0909221607q2705f92cyba2fd714da824742@mail.gmail.com>
Message-ID: <16B130455E5C4BCFA6D4726D621C6012@experienbd1776>

The 7600 supports NSF/SSO (Non-Stop Forwarding, Stateful Supervisor 
O(something)) essentially giving you the <5sec recovery but the neighbors 
need to be NSF Aware.

Or you can use RPR+ (the 30secs version) and ensure your layer3 network 
routes around the missing box in well under a second.

For our core - we're taking the second option.



----- Original Message ----- 
From: "Nick Colton" <networkjedi at geekwhore.net>
To: <cisco-nsp at puck.nether.net>
Sent: Wednesday, September 23, 2009 12:07 AM
Subject: [c-nsp] Cisco 7600 vs ASR 9000


>I work for a small CLEC, we have been doing FTTP for 5 years now but are
> getting ready to update our core network and introduce IPTV services. 
> Cisco
> has been recommending the Cisco 7600 as our core router.  My concern is 
> that
> cisco told us that in the event of an RSP fail over the 7600 could take up
> to 30 seconds to begin routing packets again, this seems wrong to me since
> my old Extreme Networks BD 6808 can do fail overs and rebuild route tables
> in under 5 seconds but??  More recently I have been reading up on the ASR
> 9000 however and it appears that it would be better sized for our company
> than the 7600.  A few questions I have for the group.
> 1.  Has anyone used the ASR 9000 in place of a Cisco 7600?
>
> 2.  Is the ASR 9000 Carrier ready?  Meaning 5x9's of availability, few
> component failures, solid software...etc
>
> 3.  Has anyone had issues where it took the 7600 30 seconds to start 
> routing
> again after an RSP fail over?
>
> Thanks,
>
> Nick
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> __________ NOD32 4448 (20090922) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
> 


From achatz at forthnet.gr  Wed Sep 23 03:50:59 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Wed, 23 Sep 2009 10:50:59 +0300
Subject: [c-nsp] 7600-ES20 L2 and L3 Multiplexing
In-Reply-To: <1495C1CED4CF4D488DEC7D104491205C@int.convex.pt>
References: <291C64EB0C1842DD897DEFED84820A94@int.convex.pt>
	<1495C1CED4CF4D488DEC7D104491205C@int.convex.pt>
Message-ID: <4AB9D363.1070504@forthnet.gr>

I'm using SRD2 and ES+ cards, but i haven't met your issue.

IPv6 is working fine under subinterfaces, together with other service instances on the 
same physical interface.


-- 
Tassos


Antonio Soares wrote on 22/09/2009 18:13:
> Hello group,
> 
> I received some off-line help and now i have a workaround:
> 
> +++++++++++++++++++++++++
>  !
>  service instance 200 ethernet
>   encapsulation dot1q 200 second-dot1q 100
>   rewrite ingress tag pop 2 symmetric
>   bridge-domain 200
>  !
> !
> interface Vlan200
>  ip address 20.20.20.254 255.255.255.0
>  ipv6 address 2001:20::2/64
> !
> +++++++++++++++++++++++++
> 
> Now there is a document about the ES20 that says the following:
> 
> "Flexible QinQ Mapping and Service Awareness on 7600-ESM-2X10GE and 7600-ESM-20X1GE is supported only through Ethernet Virtual
> Connection Services (EVCS) service instances."
> 
> "The Flexible QinQ Mapping and Service Awareness on 7600-ESM-2X10GE and 7600-ESM-20X1GE feature allows service providers to offer
> triple-play services, residential internet access from a DSLAM, and business Layer 2 and Layer 3 VPN by providing for termination of
> double-tagged dot1q frames onto a Layer 3 subinterface at the access node."
> 
> Source:
> 
> http://www.cisco.com/en/US/products/hw/routers/ps368/products_configuration_guide_chapter09186a00807f3f97.html#wp1433597
> 
> 
> I still do not understand if L3 sub-interfaces are supported or not and if they are, why IPv6 commands are not accepted.
> 
> 
> Thanks.
> 
> Regards,
> 
> Antonio Soares, CCIE #18473 (R&S)
> amsoares at netcabo.pt
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Antonio Soares
> Sent: segunda-feira, 21 de Setembro de 2009 17:29
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] 7600-ES20 L2 and L3 Multiplexing
> 
> Hello group,
> 
> I have a ES20 interface configured with L2 services via the "service instance" command. Now i would like to add L3 services to the
> same physical interface but i noticed a problem with IPv6:
> 
> 7600#
> 7600#conf t
> Enter configuration commands, one per line.  End with CNTL/Z.
> 7600(config)#!
> 7600(config)#interface GigabitEthernet3/0/0.200100
> 7600(config-subif)# encapsulation dot1Q 200 second-dot1q 100
> 7600(config-subif)# ip address 20.20.20.254 255.255.255.0
> 7600(config-subif)# ipv6 address 2001:20::2/64
>                        ^
> % Invalid input detected at '^' marker.
>  
> 7600(config-subif)#ipv6 ?    
> % Unrecognized command
> 7600(config-subif)#
> 
> After removing all the service instance entries, the IPv6 command was accepted. Is this a known limitation ? I saw the same problem
> with 12.2(33)SRC2 and 122-33.SRD2a.
> 
> 
> Thanks.
> 
> Regards,
> 
> Antonio Soares, CCIE #18473 (R&S)
> amsoares at netcabo.pt
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 

From frosya84 at mail.ru  Wed Sep 23 04:10:53 2009
From: frosya84 at mail.ru (=?koi8-r?Q?=EF=CC=D8=C7=C1_=F2=D5=D6=C1=CE=D3=CB=C1=D1?=)
Date: Wed, 23 Sep 2009 12:10:53 +0400
Subject: [c-nsp] Inter-AS L2VPN redundancy, option B (Ruzhanskaya Olga)
Message-ID: <E1MqMw9-0005oY-00.frosya84-mail-ru@f112.mail.ru>

Hello List!

My company is working on building Inter-AS VPN connection with other provider (both using MPLS).
After researching on different option we've decided to use Option B (single-hop MP-EBGP).
The only way to build l2vpn for option B is to use point-to-point VFI on ASBRs:
http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_l2vpn_pseudo_swit_ps6922_TSD_Products_Configuration_Guide_Chapter.html#wp1059907

We've found information how to build redundant schemes for L3VPN, but redundancy for l2vpn is a problem..
If we have the following topology (2 ASBRs in one AS with connections to 1 ASBR in other AS):
ASBR2(AS2)
   | 
ASBR1(AS1)
   |
ASBR3(AS2)  
is it possible to build a redundant l2vpn?

As I understand, to use L2VPN Pseudowire Redundancy, we need directed control protocol between the peer routers, and there is no such protocol (LDP, for example) in nature of option B. 
But maybe someone have already decided such question?

I will be very glad for any suggestions/documents(it is so little information about inter-as l2!)

Best regards, 
Olga


From jckdaniels12 at gmail.com  Wed Sep 23 03:50:45 2009
From: jckdaniels12 at gmail.com (jack daniels)
Date: Wed, 23 Sep 2009 13:20:45 +0530
Subject: [c-nsp] OSPF to ISIS migartion
Message-ID: <8bb137f40909230050vce3c824mc31113a20bfde129@mail.gmail.com>

Hi all ,
I have got a project for an ISP ( also LDP configured ) runnning OSPF to
migrate to IS-IS.
I was planning to runnn dual IGP , as ospf with AD 110 and ISIS with AD 115
, OSPF will always be preffered.
I was planning the challenges for migration, below are the ones which I
could think of , please give your inputs on WHAT CONSIDERATIONS TO KEEP IN
MIND BEFORE MIGRATION.
Also request you to share some docs for migration of OSPF to ISIS<<<<<

1)  MEMORY/CPU utilisation
2)  no. of routes in routing table and database
3)  harware of the cisco devices ( 7206/12K)


Regards

From amsoares at netcabo.pt  Wed Sep 23 05:36:02 2009
From: amsoares at netcabo.pt (Antonio Soares)
Date: Wed, 23 Sep 2009 10:36:02 +0100
Subject: [c-nsp] 7600-ES20 L2 and L3 Multiplexing
In-Reply-To: <4AB9D363.1070504@forthnet.gr>
References: <291C64EB0C1842DD897DEFED84820A94@int.convex.pt><1495C1CED4CF4D488DEC7D104491205C@int.convex.pt>
	<4AB9D363.1070504@forthnet.gr>
Message-ID: <471E7F4D6CC54E2092C1B586E10E322A@int.convex.pt>

Thank you for this feedback. So it must be something related with the ES card. You have an ES+ and i have an ES. I need to check the
ES+ documents to see if there is a reference to this.


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tassos Chatzithomaoglou
Sent: quarta-feira, 23 de Setembro de 2009 8:51
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] 7600-ES20 L2 and L3 Multiplexing

I'm using SRD2 and ES+ cards, but i haven't met your issue.

IPv6 is working fine under subinterfaces, together with other service instances on the same physical interface.


-- 
Tassos


Antonio Soares wrote on 22/09/2009 18:13:
> Hello group,
> 
> I received some off-line help and now i have a workaround:
> 
> +++++++++++++++++++++++++
>  !
>  service instance 200 ethernet
>   encapsulation dot1q 200 second-dot1q 100
>   rewrite ingress tag pop 2 symmetric
>   bridge-domain 200
>  !
> !
> interface Vlan200
>  ip address 20.20.20.254 255.255.255.0
>  ipv6 address 2001:20::2/64
> !
> +++++++++++++++++++++++++
> 
> Now there is a document about the ES20 that says the following:
> 
> "Flexible QinQ Mapping and Service Awareness on 7600-ESM-2X10GE and 7600-ESM-20X1GE is supported only through Ethernet Virtual
> Connection Services (EVCS) service instances."
> 
> "The Flexible QinQ Mapping and Service Awareness on 7600-ESM-2X10GE and 7600-ESM-20X1GE feature allows service providers to offer
> triple-play services, residential internet access from a DSLAM, and business Layer 2 and Layer 3 VPN by providing for termination
of
> double-tagged dot1q frames onto a Layer 3 subinterface at the access node."
> 
> Source:
> 
> http://www.cisco.com/en/US/products/hw/routers/ps368/products_configuration_guide_chapter09186a00807f3f97.html#wp1433597
> 
> 
> I still do not understand if L3 sub-interfaces are supported or not and if they are, why IPv6 commands are not accepted.
> 
> 
> Thanks.
> 
> Regards,
> 
> Antonio Soares, CCIE #18473 (R&S)
> amsoares at netcabo.pt
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Antonio Soares
> Sent: segunda-feira, 21 de Setembro de 2009 17:29
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] 7600-ES20 L2 and L3 Multiplexing
> 
> Hello group,
> 
> I have a ES20 interface configured with L2 services via the "service instance" command. Now i would like to add L3 services to the
> same physical interface but i noticed a problem with IPv6:
> 
> 7600#
> 7600#conf t
> Enter configuration commands, one per line.  End with CNTL/Z.
> 7600(config)#!
> 7600(config)#interface GigabitEthernet3/0/0.200100
> 7600(config-subif)# encapsulation dot1Q 200 second-dot1q 100
> 7600(config-subif)# ip address 20.20.20.254 255.255.255.0
> 7600(config-subif)# ipv6 address 2001:20::2/64
>                        ^
> % Invalid input detected at '^' marker.
>  
> 7600(config-subif)#ipv6 ?    
> % Unrecognized command
> 7600(config-subif)#
> 
> After removing all the service instance entries, the IPv6 command was accepted. Is this a known limitation ? I saw the same
problem
> with 12.2(33)SRC2 and 122-33.SRD2a.
> 
> 
> Thanks.
> 
> Regards,
> 
> Antonio Soares, CCIE #18473 (R&S)
> amsoares at netcabo.pt
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



From wmaton at ryouko.imsb.nrc.ca  Wed Sep 23 05:49:32 2009
From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor)
Date: Wed, 23 Sep 2009 05:49:32 -0400 (EDT)
Subject: [c-nsp] OSPF to ISIS migartion
In-Reply-To: <8bb137f40909230050vce3c824mc31113a20bfde129@mail.gmail.com>
References: <8bb137f40909230050vce3c824mc31113a20bfde129@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0909230548200.19816@ryouko.imsb.nrc.ca>

On Wed, 23 Sep 2009, jack daniels wrote:

> Hi all ,
> I have got a project for an ISP ( also LDP configured ) runnning OSPF to
> migrate to IS-IS.
> I was planning to runnn dual IGP , as ospf with AD 110 and ISIS with AD 115
> , OSPF will always be preffered.
> I was planning the challenges for migration, below are the ones which I
> could think of , please give your inputs on WHAT CONSIDERATIONS TO KEEP IN
> MIND BEFORE MIGRATION.
> Also request you to share some docs for migration of OSPF to ISIS<<<<<

You shuld have a look at a couple of URLs for ome hints:

Vijay's OSPF to ISIS migration at AOL:

http://www.vijaygill.com/oi.pdf

Dave Katz's notes:

http://www.nanog.org/mtg-0006/katz.html

wfms

From lists at quux.de  Wed Sep 23 06:44:33 2009
From: lists at quux.de (Jens Link)
Date: Wed, 23 Sep 2009 12:44:33 +0200
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <87y6o747nm.fsf@laphroiag.quux.de> (Jens Link's message of "Tue\,
	22 Sep 2009 12\:04\:45 +0200")
References: <4AAFD139.4050402@west.net> <4AAFD6B9.4050903@forthnet.gr>
	<4AAFD842.6030801@west.net> <4AAFDB58.4040204@rollernet.us>
	<4AAFE01C.3080602@cisco.com>
	<5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>
	<20090918103632.GT1508@greenie.muc.de>
	<DD8F8D35B252094B813ADA95905F4AFD21216127B4@ukexhcm1.lbi.local>
	<20090918114057.GU1508@greenie.muc.de>
	<2C05E949E19A9146AF7BDF9D44085B863B3E88201C@exchange.aoihq.local>
	<4AB82DB3.5080905@rancid.berkeley.edu>
	<BAA50624-A446-46E3-B6CD-1FB0945CF8E0@puck.nether.net>
	<87y6o747nm.fsf@laphroiag.quux.de>
Message-ID: <878wg6szxq.fsf@laphroiag.quux.de>

Jens Link <lists at quux.de> writes:

> On the bright side: Download worked for me using Debian Testing +
> Firefox. 

I stand corrected. It doesn't. :-(

Jens
-- 
-------------------------------------------------------------------------
| Foelderichstr. 40  | 13595 Berlin, Germany | +49-151-18721264         |
| http://www.quux.de | http://blog.quux.de   | jabber: jenslink at guug.de |
-------------------------------------------------------------------------

From nick at inex.ie  Wed Sep 23 06:57:46 2009
From: nick at inex.ie (Nick Hilliard)
Date: Wed, 23 Sep 2009 11:57:46 +0100
Subject: [c-nsp] "Enhanced" download procedure
In-Reply-To: <878wg6szxq.fsf@laphroiag.quux.de>
References: <4AAFD139.4050402@west.net>
	<4AAFD6B9.4050903@forthnet.gr>	<4AAFD842.6030801@west.net>
	<4AAFDB58.4040204@rollernet.us>	<4AAFE01C.3080602@cisco.com>	<5EB9799F396A304686962AFFF740ED0C016836239B@NOOSLEXCH001.adno.local>	<20090918103632.GT1508@greenie.muc.de>	<DD8F8D35B252094B813ADA95905F4AFD21216127B4@ukexhcm1.lbi.local>	<20090918114057.GU1508@greenie.muc.de>	<2C05E949E19A9146AF7BDF9D44085B863B3E88201C@exchange.aoihq.local>	<4AB82DB3.5080905@rancid.berkeley.edu>	<BAA50624-A446-46E3-B6CD-1FB0945CF8E0@puck.nether.net>	<87y6o747nm.fsf@laphroiag.quux.de>
	<878wg6szxq.fsf@laphroiag.quux.de>
Message-ID: <4AB9FF2A.8060807@inex.ie>

On 23/09/2009 11:44, Jens Link wrote:
> I stand corrected. It doesn't. :-(

Use the Greasemonkey script someone posted here the other day:

http://userscripts.org/scripts/show/58082

It cuts out all of this stupid java trash and means that downloading 
actually works and is reliable.

I wonder how hard it would be for Cisco to add a "download" link like this 
greasemonkey script.  Oh, never mind.

Nick

From jzp-cnsp at rsuc.gweep.net  Wed Sep 23 07:37:30 2009
From: jzp-cnsp at rsuc.gweep.net (Joe Provo)
Date: Wed, 23 Sep 2009 07:37:30 -0400
Subject: [c-nsp] OSPF to ISIS migartion
In-Reply-To: <Pine.LNX.4.64.0909230548200.19816@ryouko.imsb.nrc.ca>
References: <8bb137f40909230050vce3c824mc31113a20bfde129@mail.gmail.com>
	<Pine.LNX.4.64.0909230548200.19816@ryouko.imsb.nrc.ca>
Message-ID: <20090923113728.GA94429@gweep.net>

On Wed, Sep 23, 2009 at 05:49:32AM -0400, William F. Maton Sotomayor wrote:
> On Wed, 23 Sep 2009, jack daniels wrote:
> 
> >Hi all ,
> >I have got a project for an ISP ( also LDP configured ) runnning OSPF to
> >migrate to IS-IS.
> >I was planning to runnn dual IGP , as ospf with AD 110 and ISIS with AD 115
> >, OSPF will always be preffered.
> >I was planning the challenges for migration, below are the ones which I
> >could think of , please give your inputs on WHAT CONSIDERATIONS TO KEEP IN
> >MIND BEFORE MIGRATION.
> >Also request you to share some docs for migration of OSPF to ISIS<<<<<

If you are worried about memory, you should re-examine what is in your 
IGP.  

See also the isis design guide, section 4 "Migration".

-- 
             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

From david.freedman at uk.clara.net  Wed Sep 23 07:49:11 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Wed, 23 Sep 2009 12:49:11 +0100
Subject: [c-nsp] OSPF to ISIS migartion
In-Reply-To: <8bb137f40909230050vce3c824mc31113a20bfde129@mail.gmail.com>
References: <8bb137f40909230050vce3c824mc31113a20bfde129@mail.gmail.com>
Message-ID: <h9d1vn$5mm$1@ger.gmane.org>

jack daniels wrote:
> Hi all ,
> I have got a project for an ISP ( also LDP configured ) runnning OSPF to
> migrate to IS-IS.

Please make sure you understand your reasons for doing so clearly before
you get started with this, examples:

Good reasons:

 - Want to completely re-engineer the IGP nondisruptively (leverage
admin-distance)

 - Want to merge with another IS-IS network which can't migrate to OSPF

Bad reasons:

 - Want to switch on LDP but don't want loads of FECS (bad: use
advertise filter)

 - Want to move to IPv6 (bad, try OSPFv3)

 - Our new-guy only understands IS-IS (bad: get a new new-guy)

etc..

Dave.


From andy.petrenko at gmail.com  Wed Sep 23 08:12:55 2009
From: andy.petrenko at gmail.com (Andrey 'sshd' Petrenko)
Date: Wed, 23 Sep 2009 15:12:55 +0300
Subject: [c-nsp] Inter-AS L2VPN redundancy, option B (Ruzhanskaya Olga)
In-Reply-To: <E1MqMw9-0005oY-00.frosya84-mail-ru@f112.mail.ru>
References: <E1MqMw9-0005oY-00.frosya84-mail-ru@f112.mail.ru>
Message-ID: <6b300f5d0909230512o17b8dbd6t6e64554a8ed8e33b@mail.gmail.com>

Book MPLS Configuration on Cisco IOS Software.  Implementing Layer 2 VPNs
over Inter-AS Topologies Using Layer 2 VPN Pseudo-Wire Switching.


23 ???????? 2009 ?. 11:10 ???????????? ????? ?????????
<frosya84 at mail.ru>???????:

> Hello List!
>
> My company is working on building Inter-AS VPN connection with other
> provider (both using MPLS).
> After researching on different option we've decided to use Option B
> (single-hop MP-EBGP).
> The only way to build l2vpn for option B is to use point-to-point VFI on
> ASBRs:
>
> http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_l2vpn_pseudo_swit_ps6922_TSD_Products_Configuration_Guide_Chapter.html#wp1059907
>
> We've found information how to build redundant schemes for L3VPN, but
> redundancy for l2vpn is a problem..
> If we have the following topology (2 ASBRs in one AS with connections to 1
> ASBR in other AS):
> ASBR2(AS2)
>   |
> ASBR1(AS1)
>   |
> ASBR3(AS2)
> is it possible to build a redundant l2vpn?
>
> As I understand, to use L2VPN Pseudowire Redundancy, we need directed
> control protocol between the peer routers, and there is no such protocol
> (LDP, for example) in nature of option B.
> But maybe someone have already decided such question?
>
> I will be very glad for any suggestions/documents(it is so little
> information about inter-as l2!)
>
> Best regards,
> Olga
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



-- 
With best regards,
     Andrey 'sshd' Petrenko
     xmmp: sshd at jabber.org
     gtalk: andy.petrenko at gmail.com
     skype: andy.petrenko
     web: http://sshd.by

From justin at justinshore.com  Wed Sep 23 09:02:59 2009
From: justin at justinshore.com (Justin Shore)
Date: Wed, 23 Sep 2009 08:02:59 -0500
Subject: [c-nsp] OSPF to ISIS migartion
In-Reply-To: <8bb137f40909230050vce3c824mc31113a20bfde129@mail.gmail.com>
References: <8bb137f40909230050vce3c824mc31113a20bfde129@mail.gmail.com>
Message-ID: <4ABA1C83.9000803@justinshore.com>

jack daniels wrote:
> Hi all ,
> I have got a project for an ISP ( also LDP configured ) runnning OSPF to
> migrate to IS-IS.
> I was planning to runnn dual IGP , as ospf with AD 110 and ISIS with AD 115
> , OSPF will always be preffered.
> I was planning the challenges for migration, below are the ones which I
> could think of , please give your inputs on WHAT CONSIDERATIONS TO KEEP IN
> MIND BEFORE MIGRATION.
> Also request you to share some docs for migration of OSPF to ISIS<<<<<
> 
> 1)  MEMORY/CPU utilisation
> 2)  no. of routes in routing table and database
> 3)  harware of the cisco devices ( 7206/12K)

Vijay from AOL did such a migration.  If memory serves me correctly he 
migrated all of AOL in 2 days.  Day 1 was the migration of their test 
POP.  Day 2 was everything in production.

http://www.nanog.org/meetings/nanog29/abstracts.php?pt=Njg2Jm5hbm9nMjk=&nm=nanog29

Here's another NANOG IS-IS presentation.

http://www.nanog.org/meetings/nanog24/abstracts.php?pt=OTA2Jm5hbm9nMjQ=&nm=nanog24


If you search NANOG's resources page you'll find several IS-IS 
presentations.

http://www.nanog.org/resources/tutorials/

How many routes does your IGP carry today?  Perhaps you should first 
move your customer routers into iBGP before you proceed with the IGP 
change.  That will ensure that your IGP is small.  Unless it's extremely 
large or your edge routers are on the verge of collapse, I wouldn't 
worry about the size too much.

You need to make sure that IS-IS is supported on all your current 
platforms.  There are some that you may currently utilize that don't 
support IS-IS at all.  For example most fixed configuration Cat switches 
don't support it, though a few do (ME3750 for example).  You may need to 
bump featuresets to get full IS-IS support in some cases as well so 
definitely make use of Cisco's Feature Navigator.

Also, and I'm speaking from my own experience with a thoroughly messed 
up OSPF deployment to a flat L2 IS-IS deployment, when you start the 
migration don't stop until the migration is complete.  Do not leave bits 
and pieces of the network unmigrated, assuming that you'll come back 
later and fix it.  I made that mistake.  I guarantee you that dualing 
IGPs and/or redistribution will bite you in the ass.  There is nothing 
quite like the look on one's face when you discover that the routing 
between your core routers happens to get routed through a stack of EMI 
3750s that is connected to both core routers.  Oh yeah.  Not pretty. 
Don't make the same mistake.  Do it Vijay's way; all at once.

Best of luck
  Justin

From ddungui at gmail.com  Wed Sep 23 10:20:04 2009
From: ddungui at gmail.com (Donato Dunguihual Morales)
Date: Wed, 23 Sep 2009 10:20:04 -0400
Subject: [c-nsp] Cisco SCE OIDs
In-Reply-To: <BLU102-W26A58AB11ADE9692C4D0F6FADC0@phx.gbl>
References: <BLU102-W26A58AB11ADE9692C4D0F6FADC0@phx.gbl>
Message-ID: <4ABA2E94.6080702@gmail.com>

Hi Mohammad.

Cisco recommend the utility rtmcd (windows and linux version)

http://www.cisco.com/en/US/products/ps6135/products_user_guide09186a00808165dd.html#o16501

In my case it was impossible setup in linux server   :-(   , i did not 
probe in windows.  Few days ago, Gergi Genov post  a solution with cacti 
and sce template.

http://forums.cacti.net/viewtopic.php?t=30931&start=0&postdays=0&postorder=asc&highlight=

this  works  fine , however is the total of protocols in the  box, not 
for package or subscriber.


Good luck.

Donato



> hey all 
> i have cisco sce with the below version
>
> System version: Version 3.5.0 Build 407
> Build time: Dec 22 2008, 18:28:53 (Change-list 414717)
> Software version is: Version 3.5.0 Build 407
> Cryptography class: K9
> Hardware information is:
>
> ---------------------
> Firmware
> ---------------------
> kernel      : [kernel] 2.0.0/6 (inactive: [kernel] 1.1.0/8)
> u-boot      : [uboot] 1.2.0/4 (field: [uboot] 0.8.1/18)
> select      : [ubs-cf1] 1.1.0/8 (secondary: [ubs-cf1] 1.1.0/8)
>
> Platform: SCE8000 - 2x10GBE
> Management agent interface version: SCE Agent 3.5.0 Build 469
> Software package file: Not available
>
> i am trying to graph some parameters such as the concurrent sessions and per package download
>
>
>
> [failsafe at CORE ~]$ snmpwalk -v2c -c  community x.x.x.x
> .1.3.6.1.4.1.5655.4.1.8.1.1.9.1
>
> SNMPv2-SMI::enterprises.5655.4.1.8.1.1.9.1 = No Such Object
> available on this agent at this OID
>
>
> any ideas?
>
> thanks
>
> _________________________________________________________________
> With Windows Live, you can organize, edit, and share your photos.
> http://www.microsoft.com/middleeast/windows/windowslive/products/photo-gallery-edit.aspx
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>   


From rens at autempspourmoi.be  Wed Sep 23 10:35:21 2009
From: rens at autempspourmoi.be (Rens)
Date: Wed, 23 Sep 2009 16:35:21 +0200
Subject: [c-nsp] ospf hellos
Message-ID: <B3BB2565B39146A19ED745475660C165@EU.corp.clearwire.com>

Hi,

 

Is there a way to prioritize ospf hello packets with 802.1p?

The reason for this is that I have wireless link between 2 routers and often
the ospf adjacency goes down/up very quickly and I can enable 802.1p
priority on this wireless link.

 

Regards,

 

Rens


From psirt at cisco.com  Wed Sep 23 12:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Object-group
	Access Control List Bypass Vulnerability
Message-ID: <200909231215.acl@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Object-group Access
Control List Bypass Vulnerability

Advisory ID: cisco-sa-20090923-acl

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

A vulnerability exists in Cisco IOS? software where an
unauthenticated attacker could bypass access control policies when
the Object Groups for Access Control Lists (ACLs) feature is used.
Cisco has released free software updates that address this
vulnerability. There are no workarounds for this vulnerability other
than disabling the Object Groups for ACLs feature.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-acl.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

Vulnerable Products
+------------------

Any Cisco device configured with ACLs using the object group feature
and running an affected Cisco IOS software version is affected by
this vulnerability.

Note: The Object Groups for ACLs feature was introduced in Cisco IOS
software version 12.4(20)T.

To verify whether object groups are configured in a Cisco IOS device,
use the "show object-group" command in user EXEC or privileged EXEC
mode. The following example displays a sample output from the "show
object-group" command when object groups are configured:

    Router# show object-group
    Network object group my_host_group
     host 172.18.104.123
    
    Service object group my_allowed_services
     tcp eq www
     tcp eq 443

Alternatively, administrators can also use the "show running config |
include ^ (permit|deny) .*object-group" command to verify whether
object groups are configured, as shown in the following example:

    Router#show running-config | include ^ (permit|deny) .*object-group
     permit object-group my_allowed_services host 10.10.1.1 host 10.20.1.1
     permit tcp any object-group my_host_group eq 22

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
    Cisco Internetwork Operating System Software
    IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by cisco Systems, Inc.
    Compiled Mon 17-Mar-08 14:39 by dchih
    
    
    !--- output truncated
    

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.4(20)T with an installed image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team
    
    
    !--- output truncated
    

Products Confirmed Not Vulnerable
+--------------------------------

Cisco devices that are not configured with object groups are not
vulnerable.

Cisco IOS XE Software and Cisco IOS XR Software are not affected by
this vulnerability.

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

In Cisco IOS Software an object group can contain a single object
(such as a single IP address, network, or subnet) or multiple objects
(such as a combination of multiple IP addresses, networks, or
subnets). In an ACL that is based on an object group, administrators
can create a single access control entry (ACE) that uses an object
group name instead of creating many ACEs, which each would require a
different IP address. A similar object group, such as a protocol port
group, can be extended to limit access to a set of applications for a
user group to a server group.

A vulnerability exists in Cisco IOS Software that could allow an
unauthenticated attacker to bypass access control policies when the
Object Groups for ACLs feature is used.

Note: The Object Groups for ACLs feature was introduced in Cisco IOS
software version 12.4(20)T.

This vulnerability is documented in the following Cisco Bug IDs:

  * CSCsx07114
  * CSCsu70214
  * CSCsw47076
  * CSCsv48603
  * CSCsy54122
  * CSCsu50252

This vulnerability has been assigned Common Vulnerabilities and
Exposures (CVE) identifier CVE-2009-2862.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss

CSCsx07114, CSCsu70214, CSCsw47076, CSCsv48603, CSCsy54122, CSCsu50252 -
Object-group Access Control List Bypass

CVSS Base Score - 4.3

Access Vector           - Network
Access Complexity       - Medium
Authentication          - None
Confidentiality Impact  - Parital
Integrity Impact        - None
Availability Impact     - none

CVSS Temporal Score - 3.6

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability may allow an attacker to
access resources that should be protected by the Cisco IOS device.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.0-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.1-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.2-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.3-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.3 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.4-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
| 12.4       | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.4GC     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
| 12.4JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(11)MD9  |
|            |                                       |              |
| 12.4MD     | 12.4(22)MD1                           | 12.4(15)MD3  |
|            |                                       |              |
|            |                                       | 12.4(22)MD1  |
|------------+---------------------------------------+--------------|
| 12.4MDA    | 12.4(22)MDA1                          | 12.4(22)MDA1 |
|------------+---------------------------------------+--------------|
| 12.4MR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4SW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(20)T4   |
|            | 12.4(22)T2                            |              |
|            |                                       | 12.4(22)T3   |
| 12.4T      | 12.4(20)T4                            |              |
|            |                                       | 12.4(24)T2;  |
|            | 12.4(24)T1                            | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4XA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XN     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XP     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XT     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XV     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
|            |                                       | 12.4(22)T3   |
| 12.4XZ     | Vulnerable; first fixed in 12.4T      |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(22)T3   |
|            |                                       |              |
| 12.4YA     | Vulnerable; first fixed in 12.4T      | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4YB     | 12.4(22)YB4                           | 12.4(22)YB4  |
|------------+---------------------------------------+--------------|
| 12.4YD     | 12.4(22)YD1                           | 12.4(22)YD1  |
|------------+---------------------------------------+--------------|
| 12.4YE     | 12.4(22)YE1                           | 12.4(22)YE1  |
|------------+---------------------------------------+--------------|
| 12.4YG     | Not Vulnerable                        |              |
+-------------------------------------------------------------------+

Note: No Cisco IOS-XE or Cisco IOS Software Modularity releases are
affected by this vulnerability.

Workarounds
===========

There are no workarounds for this vulnerability other than disabling
the Object Groups for ACLs feature.

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at:

http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html

or as otherwise set forth at Cisco.com Downloads at:

http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to:

http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html

for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was found during internal testing.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-acl.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+----------------------------------------+
| Revision |                   | Initial |
| 1.0      | 2009-September-23 | public  |
|          |                   | release |
+----------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and
registering to receive security information from Cisco, is available
on Cisco's worldwide website at:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

This includes instructions for press inquiries regarding Cisco security
notices. All Cisco security advisories are available at:

http://www.cisco.com/go/psirt
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukF586n/Gc8U/uARAuXEAJ99dU6Wi1fZMY1yNgedSCx4/+0p8wCeOSKF
HmMwzq017QkqDzBFo/JH6DQ=
=XJAG
-----END PGP SIGNATURE-----

From psirt at cisco.com  Wed Sep 23 12:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: [c-nsp] Cisco Security Advisory: Cisco Unified Communications
	Manager Express Vulnerability
Message-ID: <200909231215.cme@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco Unified Communications Manager Express
Vulnerability

Advisory ID: cisco-sa-20090923-cme

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

Cisco IOS? devices that are configured for Cisco Unified
Communications Manager Express (CME) and the Extension Mobility
feature are vulnerable to a buffer overflow vulnerability. Successful
exploitation of this vulnerability may result in the execution of
arbitrary code or a Denial of Service (DoS) condition on an affected
device.

Cisco has released free software updates that address this
vulnerability.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-cme.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

Cisco IOS devices, including Cisco Unified Communications 500 Series,
that are configured for Cisco Unified CME and the Extension Mobility
feature are affected.

Vulnerable Products
+------------------

A Cisco IOS device that is configured for Cisco Unified CME and
Extension Mobility contains the following output when the show
running-config command is issued:

    ephone [Ethernet phone tag]
      ...
      logout-profile [logout-profile tag]

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the 
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name is displayed in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

        Router#show version
        Cisco Internetwork Operating System Software
        IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
        Technical Support: http://www.cisco.com/techsupport
        Copyright (c) 1986-2008 by cisco Systems, Inc.
        Compiled Mon 17-Mar-08 14:39 by dchih
    
        <output truncated>

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.4(20)T with an installed image name of
C1841-ADVENTERPRISEK9-M:

        Router#show version
        Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
        Technical Support: http://www.cisco.com/techsupport
        Copyright (c) 1986-2008 by Cisco Systems, Inc.
        Compiled Thu 10-Jul-08 20:25 by prod_rel_team
    
        <output truncated>

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link: http://www.cisco.com/warp/public/620/1.html .

Products Confirmed Not Vulnerable
+--------------------------------

Cisco IOS devices that are configured for Survivable Remote Site
Telephony (SRST) Mode are not affected.

Cisco IOS XR is not affected.

Cisco IOS XE is not affected.

Cisco Unified Communications Manager is not affected.

Cisco Unified CME is not affected unless configured to use the
Extension Mobility feature.

No other Cisco products are currently known to be affected by these
vulnerabilities.

Details
=======

Cisco Unified CME is the call processing component of an enhanced IP
telephony solution that is integrated into Cisco IOS.

The Extension Mobility feature in Cisco Unified CME provides the
benefit of phone mobility for end users. A user login service allows
phone users to temporarily access a physical phone other than their
own phone and utilize their personal settings, such as directory
number, speed-dial lists, and services, that is assigned to their own
desk phone. The phone user can make and receive calls on that phone
using the same personal directory number as is on their own desk
phone. More information on Extension Mobility feature is available at
the following URL:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmemobl.html

A vulnerability in the login section of the Extension Mobility
feature may allow an unauthenticated attacker to execute arbitrary
code or cause a Denial of Service (DoS) condition. Such packets can
only come from registered phone IP addresses in the form of HTTP
requests. If the auto-registration feature is enabled, an attacker
can register its IP address and subsequently send a crafted payload
to exploit this vulnerability. The auto-registration feature is
enabled by default. More information on auto-registration can be
found at the following link:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/command/reference/cme_a1ht.html#wp1031242.

This vulnerability is addressed by the Cisco Bug ID CSCsq58779 and has
been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-2865.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerabilities in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss

CSCsq58779 - Vulnerability in Extension Mobility Feature

CVSS Base Score - 7.6

Access Vector           - Network
Access Complexity       - High
Authentication          - None
Confidentiality Impact  - Complete
Integrity Impact        - Complete
Availability Impact     - Complete

CVSS Temporal Score - 6.3

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of this vulnerability may result in the
execution of arbitrary code or a Denial of Service (DoS) condition on
an affected device.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|    Major Release     |        Availability of Repaired Releases   |
|----------------------+--------------------------------------------|
| Affected 12.0-Based  |  First Fixed  |    Recommended Release     |
|       Releases       |    Release    |                            |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases.                        |
|-------------------------------------------------------------------|
| Affected 12.1-Based  |  First Fixed  |    Recommended Release     |
|       Releases       |    Release    |                            |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases.                        |
|-------------------------------------------------------------------|
| Affected 12.2-Based  |  First Fixed  |    Recommended Release     |
|       Releases       |    Release    |                            |
|-------------------------------------------------------------------|
| There are no affected 12.2 based releases.                        |
|-------------------------------------------------------------------|
| Affected 12.3-Based  |  First Fixed  |    Recommended Release     |
|       Releases       |    Release    |                            |
|-------------------------------------------------------------------|
| There are no affected 12.3 based releases.                        |
|-------------------------------------------------------------------|
| Affected 12.4-Based  |  First Fixed  |    Recommended Release     |
|       Releases       |    Release    |                            |
|----------------------+---------------+----------------------------|
| 12.4                 | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4GC               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JA               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JDA              | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JDC              | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JDD              | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JK               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JL               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JMA              | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JMB              | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JX               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4MD               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4MDA              | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4MR               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4SW               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4T                | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XA               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XB               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XC               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XD               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XE               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XF               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XG               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XJ               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XK               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XL               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XM               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XN               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XP               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XQ               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XR               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XT               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XV               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
|                      |               | 12.4(20)T4                 |
|                      |               |                            |
| 12.4XW               | 12.4(11)XW8   | 12.4(22)T3                 |
|                      |               |                            |
|                      |               | 12.4(24)T2; Available on   |
|                      |               | 23-OCT-2009                |
|----------------------+---------------+----------------------------|
|                      |               | 12.4(20)T4                 |
|                      |               |                            |
| 12.4XY               | 12.4(15)XY4   | 12.4(22)T3                 |
|                      |               |                            |
|                      |               | 12.4(24)T2; Available on   |
|                      |               | 23-OCT-2009                |
|----------------------+---------------+----------------------------|
|                      |               | 12.4(20)T4                 |
|                      |               |                            |
| 12.4XZ               | 12.4(15)XZ1   | 12.4(22)T3                 |
|                      |               |                            |
|                      |               | 12.4(24)T2; Available on   |
|                      |               | 23-OCT-2009                |
|----------------------+---------------+----------------------------|
|                      |               | 12.4(20)T4                 |
|                      |               |                            |
| 12.4YA               | 12.4(20)YA1   | 12.4(22)T3                 |
|                      |               |                            |
|                      |               | 12.4(24)T2; Available on   |
|                      |               | 23-OCT-2009                |
|----------------------+---------------+----------------------------|
| 12.4YB               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4YD               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4YE               | Not           |                            |
|                      | Vulnerable    |                            |
+-------------------------------------------------------------------+

Workarounds
===========

There are no workarounds to mitigate this vulnerability, other than
disabling Extension Mobility. However, auto-registration can be
disabled to make exploitation more difficult. Auto-registration can
be disabled by the following command:

    telephony-service 
      no auto-reg-ephone 

Before disabling auto-registration, all phone MAC addresses need to
be explicitly defined on the Cisco Unified CME. Otherwise phones will
not be able to register. More information on auto-registration can be
found at the following link:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/command/reference/cme_a1ht.html#wp1031242

Additional mitigations that can be deployed on Cisco devices in the
network are available in the Cisco Applied Mitigation Bulletin
companion document for this advisory, which is available at the
following link:

http://www.cisco.com/warp/public/707/cisco-amb-20090923-cme.shtml

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at:

http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html

or as otherwise set forth at Cisco.com Downloads at:

http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to:

http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html

for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was found internally.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-cme.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+----------------------------------------+
| Revision |                   | Initial |
| 1.0      | 2009-September-23 | public  |
|          |                   | release |
+----------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and
registering to receive security information from Cisco, is available
on Cisco's worldwide website at:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

This includes instructions for press inquiries regarding Cisco security
notices. All Cisco security advisories are available at:

http://www.cisco.com/go/psirt
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukGH86n/Gc8U/uARAgunAJ90YNHlxpf2v1OEz8qFEo7oqmNAqACfbq6X
iHSiDV5CevynZQRrKe+sRiU=
=Fp40
-----END PGP SIGNATURE-----

From psirt at cisco.com  Wed Sep 23 12:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Zone-Based
	Policy Firewall Vulnerability
Message-ID: <200909231215.ios-fw@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Zone-Based Policy
Firewall Vulnerability

Advisory ID: cisco-sa-20090923-ios-fw

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

Cisco IOS? devices that are configured with Cisco IOS Zone-Based
Policy Firewall Session Initiation Protocol (SIP) inspection are
vulnerable to denial of service (DoS) attacks when processing a
specific SIP transit packet. Exploitation of the vulnerability could
result in a reload of the affected device.

Cisco has released free software updates that address this
vulnerability.

Workarounds that mitigate this vulnerability are available.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-ios-fw.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

This vulnerability affects a limited number of Cisco IOS Software
releases. Consult the "Software Versions and Fixes" section of this
advisory for the details of affected releases.

Only devices that are configured with Cisco IOS Zone-Based Policy
Firewall SIP inspection (UDP port 5060, TCP ports 5060, and 5061) are
vulnerable. Cisco IOS devices that are configured with legacy Cisco
IOS Firewall Support for SIP (context-based access control (CBAC))
are not vulnerable.

Vulnerable Products
+------------------

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the 
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
    Cisco Internetwork Operating System Software
    IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright ?) 1986-2008 by cisco Systems, Inc.
    Compiled Mon 17-Mar-08 14:39 by dchih
    
    <output truncated>

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.4(20)T with an installed image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright ?) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team
    
    <output truncated>

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link:

http://www.cisco.com/warp/public/620/1.html

The device is vulnerable if the configuration has either a layer 3 or
layer 7 SIP application-specific policy configured, and these
policies are applied to any firewall zone. To determine whether the
device is running a vulnerable configuration, log in to the device
and issue the command line interface (CLI) command "show policy-map
type inspect zone-pair | include atch: access|protocol sip". If the
output contains "Match: protocol sip", the device is vulnerable. If
the output contains "Match: access-group number", then the device is
only vulnerable "if", the referenced access list permits the SIP
protocol (UDP port 5060, or TCP ports 5060 and 5061). The following
example shows a vulnerable device configured with Cisco IOS
Zone-Based Policy Firewall SIP inspection:

    Router#show policy-map type inspect zone-pair | include atch: access|protocol sip
          Match: protocol sip
    Router#

The following example shows a vulnerable device configured with SIP
inspection by way of an applied access list:

    Router#show policy-map type inspect zone-pair | include atch: access|protocol sip
          Match: access-group 102
    Router#
    Router#show access-list 102
    Extended IP access list 102
        10 permit udp any any eq 5060
        20 permit tcp any any eq 5060
        30 permit tcp any any eq 5061
    Router#

A device that is not configured for SIP inspection or does not
support this configuration will return either a blank line or an
error message. The following is an example of a device that supports
Cisco IOS Firewall but does not have SIP inspection enabled:

    Router#show policy-map type inspect zone-pair | include atch: access|protocol sip
    Router#

Products Confirmed Not Vulnerable
+--------------------------------

No other Cisco products are currently known to be affected by this
vulnerability. Products confirmed not vulnerable include:

  * Cisco PIX 500 Series Firewall
  * Cisco ASA 5500 Series Adaptive Security Appliance
  * Firewall Services Module (FWSM) for Catalyst 6500 Series Switches
    and 7600 Series Routers
  * Virtual Firewall (VFW) application on the multiservice blade
    (MSB) on the Cisco XR 12000 Series Router
  * Cisco ACE Application Control Engine Module
  * Cisco IOS devices NOT configured with Cisco IOS Zone-Based Policy
    Firewall SIP inspection.
  * Cisco IOS devices configured with legacy Cisco IOS Firewall
    Support for SIP (CBAC)
  * Cisco IOS XE Software
  * Cisco IOS XR Software

Details
=======

Firewalls are networking devices that control access to the network
assets of an organization. Firewalls are often positioned at the
entrance points into networks. Cisco IOS software provides a set of
security features that enable you to configure a simple or elaborate
firewall policy, according to your particular requirements.

SIP inspection in the Cisco IOS Firewall provides basic SIP inspect
functionality (SIP packet inspection and pinhole opening) as well as
protocol conformance and application security.

Cisco IOS Software that is configured with Cisco IOS Zone-Based
Policy Firewall SIP inspection are vulnerable to a DoS attack when
processing a specific SIP transit packet. Exploitation of this
vulnerability will result in a reload of the affected device.

Cisco IOS Zone-Based Policy Firewall SIP inspection was first
introduced in Cisco IOS Software versions 12.4(15)XZ and 12.4(20)T.

Cisco IOS Firewall CBAC support for SIP inspection by way of the "ip
inspect name [inspection_name] sip" is not vulnerable. Additional
information regarding Cisco IOS Firewall CBAC support for SIP
inspection is available in the document "Firewall Support for SIP" at
the following link:

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_fwall_sip_supp.html

Additional information regarding Cisco IOS Zone-Based Policy Firewall
SIP inspection is available in the document "Cisco IOS Firewall: SIP
Enhancements: ALG and AIC" at the following link:

http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_sip_alg_aic.html

This vulnerability is documented in the following Cisco Bug ID: 
CSCsr18691 and has been assigned the Common Vulnerabilities and Exposures
(CVE) identifier CVE-2009-2867.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss

CSCsr18691 - Cisco IOS Software Zone-Based Policy Firewall

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability may result in a reload
of the affected device. Repeated exploit attempts may result in a
sustained DoS attack.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|  Major Release  |        Availability of Repaired Releases        |
|-----------------+-------------------------------------------------|
|    Affected     |                           |                     |
|   12.0-Based    |    First Fixed Release    | Recommended Release |
|    Releases     |                           |                     |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases                         |
|-------------------------------------------------------------------|
|    Affected     |                           |                     |
|   12.1-Based    |    First Fixed Release    | Recommended Release |
|    Releases     |                           |                     |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases                         |
|-------------------------------------------------------------------|
|    Affected     |                           |                     |
|   12.2-Based    |    First Fixed Release    | Recommended Release |
|    Releases     |                           |                     |
|-------------------------------------------------------------------|
| There are no affected 12.2 based releases                         |
|-------------------------------------------------------------------|
|    Affected     |                           |                     |
|   12.3-Based    |    First Fixed Release    | Recommended Release |
|    Releases     |                           |                     |
|-------------------------------------------------------------------|
| There are no affected 12.3 based releases                         |
|-------------------------------------------------------------------|
|    Affected     |                           |                     |
|   12.4-Based    |    First Fixed Release    | Recommended Release |
|    Releases     |                           |                     |
|-----------------+---------------------------+---------------------|
| 12.4            | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4GC          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JA          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JDA         | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JDC         | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JDD         | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JK          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JL          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JMA         | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JMB         | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JX          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4MD          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4MDA         | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4MR          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4SW          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
|                 | Releases prior to 12.4    | 12.4(20)T4          |
|                 | (20)T are not vulnerable; |                     |
|                 |                           | 12.4(22)T3          |
| 12.4T           | 12.4(20)T2                |                     |
|                 |                           | 12.4(24)T2;         |
|                 | 12.4(22)T1                | Available on        |
|                 |                           | 23-OCT-2009         |
|                 | 12.4(24)T                 |                     |
|-----------------+---------------------------+---------------------|
| 12.4XA          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XB          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XC          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XD          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XE          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XF          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XG          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XJ          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XK          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XL          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XM          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XN          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XP          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XQ          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XR          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XT          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XV          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XW          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XY          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
|                 |                           | 12.4(20)T4          |
|                 |                           |                     |
|                 | Vulnerable; first fixed   | 12.4(22)T3          |
| 12.4XZ          | in 12.4T                  |                     |
|                 |                           | 12.4(24)T2;         |
|                 |                           | Available on        |
|                 |                           | 23-OCT-2009         |
|-----------------+---------------------------+---------------------|
|                 |                           | 12.4(22)T3          |
|                 | Vulnerable; first fixed   |                     |
| 12.4YA          | in 12.4T                  | 12.4(24)T2;         |
|                 |                           | Available on        |
|                 |                           | 23-OCT-2009         |
|-----------------+---------------------------+---------------------|
|                 |                           | 12.4(22)YB4         |
|                 |                           |                     |
| 12.4YB          | 12.4(22)YB4               | 12.4(22)YB5;        |
|                 |                           | Available on        |
|                 |                           | 19-OCT-2009         |
|-----------------+---------------------------+---------------------|
| 12.4YD          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4YE          | Not Vulnerable            |                     |
+-------------------------------------------------------------------+

Workarounds
===========

The only workaround for this vulnerability is to disable Cisco IOS
zone-based policy firewall SIP inspection in the affected device's
configuration. Disabling SIP inspection will allow the rest of the
firewall features to continue to function until a software upgrade
can be implemented. All other firewall features will continue to
perform normally. Disabling SIP Inspection will vary depending on the
implementation of the SIP inspection firewall.

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at:

http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html

or as otherwise set forth at Cisco.com Downloads at:

http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to:

http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html

for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was discovered by Cisco internal testing.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at :

http://www.cisco.com/warp/public/707/cisco-sa-20090923-ios-fw.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+----------------------------------------+
| Revision |                   | Initial |
| 1.0      | 2009-September-23 | public  |
|          |                   | release |
+----------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and
registering to receive security information from Cisco, is available
on Cisco's worldwide website at:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

This includes instructions for press inquiries regarding Cisco security
notices. All Cisco security advisories are available at:

http://www.cisco.com/go/psirt
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukGO86n/Gc8U/uARAiwEAKCXGG7xSxS+kMllVPDdOacuAZV9vACfcVVG
3Lm0u0kNPpfW4oxa9PNOUA8=
=f0Hj
-----END PGP SIGNATURE-----

From psirt at cisco.com  Wed Sep 23 12:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Network Time
	Protocol Packet Vulnerability
Message-ID: <200909231215.ntp@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Network Time Protocol
Packet Vulnerability

Advisory ID: cisco-sa-20090923-ntp

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

Cisco IOS? Software with support for Network Time Protocol (NTP)
version (v4) contains a vulnerability processing specific NTP packets
that will result in a reload of the device. This results in a remote
denial of service (DoS) condition on the affected device.

Cisco has released free software updates that address this
vulnerability.

Workarounds that mitigate this vulnerability are available.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-ntp.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

Vulnerable Products
+------------------

Cisco IOS Software devices are vulnerable if they support NTPv4 and
are configured for NTP operations. NTP is not enabled in Cisco IOS
Software by default.

To see if a device supports NTPv4, log into the device and via
configuration mode of the command line interface (CLI), enter the
command "ntp peer 127.0.0.1 version ?". If the output has the number "4"
as an option, then the device supports NTPv4. The following example
identifies a Cisco device that is running a Cisco IOS Software
release that does support NTPv4:

    Router#configure terminal
    Router(config)#ntp peer 127.0.0.1 version ?
      <2-4>  NTP version number

The following example identifies a Cisco device that is running a
Cisco IOS Software release that does not support NTPv4:

    Router(config)#ntp peer 127.0.0.1 version ?
      <1-3>  NTP version number

To see if a device is configured with NTP, log into the device and
issue the CLI command "show running-config | include ntp". If the
output returns either of the following commands listed then the
device is vulnerable:

    ntp master <any following commands>
    ntp peer <any following commands>
    ntp server <any following commands>
    ntp broadcast client
    ntp multicast client

The following example identifies a Cisco device that is configured
with NTP:

    router#show running-config | include ntp
    ntp peer 192.168.0.12

The following example identifies a Cisco device that is not
configured with NTP:

    router#show running-config | include ntp
    router#

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the 
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
     Cisco Internetwork Operating System Software
     IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
     Technical Support: http://www.cisco.com/techsupport
     Copyright ?) 1986-2008 by cisco Systems, Inc.
     Compiled Mon 17-Mar-08 14:39 by dchih
    
     <output truncated>

The following example shows a product that is running Cisco IOS
Software release 12.4(20)T with an image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright ?) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team
    
    <output truncated>

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link:

http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+--------------------------------

The following products and features are not affected by this
vulnerability:

  * Cisco IOS Software devices without support for NTPv4
  * Cisco IOS Software devices configured with only Simple NTP (SNTP)
    feature
  * Cisco IOS XE Software
  * Cisco IOS XR Software

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

The Network Time Protocol (NTP) is a protocol designed to
time-synchronize a network of machines. NTP runs over UDP, which in
turn runs over IP. NTPv3 is documented in RFC1305 leavingcisco.com .
NTPv4 is a significant revision of the NTP standard, and is the
current development version, but has not been formalized into an RFC
at the time of publication of this advisory. NTPv4 is currently
documented in draft-ietf-ntp-ntpv4-proto-11 leavingcisco.com

When a Cisco IOS Software device supporting NTPv4 receives a specific
NTP packet it will crash while creating the NTP reply packet. The NTP
packet can be sent from any remote device, and does not require
authentication. Cisco IOS devices supporting NTPv4 and configured
with NTP peer authentication are still vulnerable. The device does
not have to be explicitly configured for NTPv4 peers. For example a
device configured with all NTP peers being explicitly labeled as
version 2 would still be vulnerable, as shown in the following
example:

    Router#show running-config | include ntp
    ntp peer 192.168.0.254 version 2
    ntp peer 192.168.0.1 version 2
    Router#

For further information on the Cisco implementation of NTP, consult
the configuration guide "Cisco IOS and NX-OS Software - Performing
Basic System Management" at the following link:

http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_basic_sys_manage.html#wp1001170

This vulnerability is documented in the following Cisco Bug IDs: 
CSCsu24505 and CSCsv75948 and has been assigned the Common Vulnerabilities
and Exposures (CVE) identifier CVE-2009-2869. Both Cisco bug IDs are
required for a full fix to this vulnerability.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss

CSCsu24505, CSCsv75948 - Cisco IOS Software NTP Packet Vulnerability

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability may result in a reload
of the device. The vulnerability could be repeatedly exploited to
cause an extended DoS condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.0-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases                         |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.1-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases                         |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.2-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.2 based releases                         |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.3-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.3 based releases                         |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.4-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
| 12.4       | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4GC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Releases prior to 12.4(22)MD are not  |              |
| 12.4MD     | vulnerable, vulnerability was first   | 12.4(22)MD1  |
|            | introduced in 12.4(22)MD, first fixed |              |
|            | in 12.4(22)MD1.                       |              |
|------------+---------------------------------------+--------------|
| 12.4MDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4SW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Releases prior to 12.4(20)T are not   |              |
|            | vulnerable.                           |              |
|            |                                       | 12.4(20)T4   |
|            | 12.4(20)T and 12.4(20)T1 are          |              |
|            | vulnerable, vulnerability is first    | 12.4(22)T3   |
| 12.4T      | fixed in 12.4(20)T2.                  |              |
|            |                                       | 12.4(24)T2;  |
|            | 12.4(22)T is vulnerable,              | Available on |
|            | vulnerability is first fixed in 12.4  | 23-OCT-2009  |
|            | (22)T1                                |              |
|            |                                       |              |
|            | 12.4(24)T is not vulnerable.          |              |
|------------+---------------------------------------+--------------|
| 12.4XA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XN     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XP     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XT     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XV     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
|            |                                       | 12.4(22)T3   |
| 12.4XZ     | Vulnerable; first fixed in 12.4T      |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
|            |                                       | 12.4(22)T3   |
| 12.4YA     | Vulnerable; first fixed in 12.4T      |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4YB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4YD     | 12.4(22)YD1                           | 12.4(22)YD1  |
|------------+---------------------------------------+--------------|
| 12.4YE     | 12.4(22)YE1                           | 12.4(22)YE1  |
+-------------------------------------------------------------------+

Workarounds
===========

There are no workarounds other than disabling NTP on the device. The
following mitigations have been identified for this vulnerability;
only packets destined for any configured IP address on the device can
exploit this vulnerability. Transit traffic will not exploit this
vulnerability.

Note: NTP peer authentication is not a workaround and is still a
vulnerable configuration.

NTP Access Group
+---------------

Warning: Because the feature in this vulnerability utilizes
UDP as a transport, it is possible to spoof the sender's IP address,
which may defeat access control lists (ACLs) that permit
communication to these ports from trusted IP addresses. Unicast
Reverse Path Forwarding (Unicast RPF) should be considered to be used
in conjunction to offer a better mitigation solution.

    
    !--- Configure trusted peers for allowed access
    
    
    access-list 1 permit 171.70.173.55
    
    
    !--- Apply ACE to the NTP configuration
    
    
    ntp access-group 1

For additional information on NTP access control groups, consult the
document titled "Performing Basic System Management" at the following
link:

http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_basic_sys_manage.html#wp1034942

Infrastructure Access Control Lists
+----------------------------------

warning Warning: Because the feature in this vulnerability utilizes
UDP as a transport, it is possible to spoof the sender's IP address,
which may defeat ACLs that permit communication to these ports from
trusted IP addresses. Unicast RPF should be considered to be used in
conjunction to offer a better mitigation solution.

Although it is often difficult to block traffic that transits a
network, it is possible to identify traffic that should never be
allowed to target infrastructure devices and block that traffic at
the border of networks. Infrastructure ACLs (iACLs) are a network
security best practice and should be considered as a long-term
addition to good network security as well as a workaround for this
specific vulnerability. The iACL example below should be included as
part of the deployed infrastructure access-list, which will help
protect all devices with IP addresses in the infrastructure IP
address range:

    
    !---
    !--- Feature: Network Time Protocol (NTP)
    !---
    
    
    access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD 
        INFRASTRUCTURE_ADDRESSES WILDCARD eq 123
    
    
    !--- Note: If the router is acting as a NTP broadcast client
    !---   via the interface command "ntp broadcast client"
    !---   then broadcast and directed broadcasts must be 
    !---   filtered as well.  The following example covers
    !---   an infrastructure address space of 192.168.0.X
    
    
    access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD 
        host 192.168.0.255 eq ntp
    access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD 
        host 255.255.255.255 eq ntp
    
    
    !--- Note: If the router is acting as a NTP multicast client
    !---   via the interface command "ntp multicast client"
    !---   then multicast IP packets to the mutlicast group must
    !---   be filtered as well.  The following example covers
    !---   a NTP multicast group of 239.0.0.1 (Default is
    !---   224.0.1.1)
    
    
    access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD 
        host 239.0.0.1 eq ntp
    
    
    !--- Deny NTP traffic from all other sources destined
    !--- to infrastructure addresses.
    
    
    access-list 150 deny udp any 
        INFRASTRUCTURE_ADDRESSES WILDCARD eq 123
    
    
    !--- Permit/deny all other Layer 3 and Layer 4 traffic in
    !--- accordance with existing security policies and
    !--- configurations.  Permit all other traffic to transit the
    !--- device.
    
    
    access-list 150 permit ip any any
    
    
    !--- Apply access-list to all interfaces (only one example
    !--- shown)
     
    
    interface fastEthernet 2/0
     ip access-group 150 in

The white paper entitled "Protecting Your Core: Infrastructure
Protection Access Control Lists" presents guidelines and recommended
deployment techniques for infrastructure protection access lists and
is available at the following link:

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml

Control Plane Policing
+---------------------

Warning: Because the feature in this vulnerability utilizes UDP as a
transport, it is possible to spoof the sender's IP address, which may
defeat ACLs that permit communication to these ports from trusted IP
addresses. Unicast RPF should be considered to be used in conjunction
to offer a better mitigation solution.

Control Plane Policing (CoPP) can be used to block untrusted UDP
traffic to the device. Cisco IOS software releases 12.0S, 12.2SX,
12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP can be
configured on a device to help protect the management and control
planes and minimize the risk and effectiveness of direct
infrastructure attacks by explicitly permitting only authorized
traffic that is sent to infrastructure devices in accordance with
existing security policies and configurations. The CoPP example below
should be included as part of the deployed CoPP, which will help
protect all devices with IP addresses in the infrastructure IP
address range.

    
    !--- Feature: Network Time Protocol (NTP)
    
    
    access-list 150 deny udp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 123
    
    
    !--- Deny NTP traffic from all other sources destined
    !--- to the device control plane.
    
    
    access-list 150 permit udp any any eq 123
    
    
    !--- Permit (Police or Drop)/Deny (Allow) all other Layer3 and 
    !--- Layer4 traffic in accordance with existing security policies
    !--- and configurations for traffic that is authorized to be sent
    !--- to infrastructure devices
    !--- Create a Class-Map for traffic to be policed by
    !--- the CoPP feature
    
    
    class-map match-all drop-udp-class
     match access-group 150
    
    
    !--- Create a Policy-Map that will be applied to the
    !--- Control-Plane of the device.
    
    
    policy-map drop-udp-traffic
     class drop-udp-class
      drop
    
    
    !--- Apply the Policy-Map to the 
    !--- Control-Plane of the device
    
    
    control-plane
     service-policy input drop-udp-traffic

In the above CoPP example, the access control list entries (ACEs)
that match the potential exploit packets with the "permit" action
result in these packets being discarded by the policy-map "drop"
function, while packets that match the "deny" action (not shown) are
not affected by the policy-map drop function. Please note that the
policy-map syntax is different in the 12.2S and 12.0S Cisco IOS
Software trains:

    policy-map drop-udp-traffic
    class drop-udp-class
    police 32000 1500 1500 conform-action drop exceed-action drop

Additional information on the configuration and use of the CoPP
feature can be found in the documents, "Control Plane Policing
Implementation Best Practices" and "Cisco IOS Software Releases 12.2
S - Control Plane Policing" at the following links:

http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html

and

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at:

http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html

or as otherwise set forth at Cisco.com Downloads at:

http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to:

http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html

for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was discovered by Cisco when handling customer
support calls.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-ntp.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+----------------------------------------+
| Revision |                   | Initial |
| 1.0      | 2009-September-23 | public  |
|          |                   | release |
+----------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and
registering to receive security information from Cisco, is available
on Cisco's worldwide website at:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

This includes instructions for press inquiries regarding Cisco security
notices. All Cisco security advisories are available at:

http://www.cisco.com/go/psirt
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukGW86n/Gc8U/uARAjmYAJ0f6SVZp7qLXI0HFG5I0cYzxtFfAACeIvG2
juvYatuemQrQUj8hfg2v0lQ=
=KnSP
-----END PGP SIGNATURE-----

From psirt at cisco.com  Wed Sep 23 12:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Session
	Initiation Protocol Denial of Service Vulnerability
Message-ID: <200909231215.sip@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Session Initiation
Protocol Denial of Service Vulnerability

Advisory ID: cisco-sa-20090923-sip

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

A vulnerability exists in the Session Initiation Protocol (SIP)
implementation in Cisco IOS? Software that could allow an
unauthenticated attacker to cause a denial of service (DoS) condition
on an affected device when the Cisco Unified Border Element feature
is enabled.

Cisco has released free software updates that address this
vulnerability. For devices that must run SIP there are no
workarounds; however, mitigations are available to limit exposure of
the vulnerability.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-sip.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

This vulnerability only affects devices running Cisco IOS Software
with SIP voice services enabled.

Vulnerable Products
+------------------

Cisco devices running affected Cisco IOS Software versions that are
configured to process SIP messages with the Cisco Unified Border
Element feature are affected. Cisco IOS devices that are not
configured for SIP and Cisco Unified Border Element feature are not
affected by this vulnerability.

Note: Cisco Unified Border Element feature (previously known as the
Cisco Multiservice IP-to-IP Gateway) is a special Cisco IOS Software
image that runs on Cisco multiservice gateway platforms. It provides
a network-to-network interface point for billing, security, call
admission control, quality of service, and signaling interworking.

Cisco Unified Border Element feature requires the "voice service voip" 
command and the "allow-connections" subcommand. An example of an
affected configuration is as follows:

     voice service voip
       allow-connections from-type to to-type 
    ...
    !

Recent versions of Cisco IOS Software do not process SIP messages by
default. Creating a dial peer by issuing the command "dial-peer voice"
will start the SIP processes, causing the Cisco IOS device to process
SIP messages. In addition, several features within Cisco Unified
Communications Manager Express, such as ePhones, once configured will
also automatically start the SIP process, which will cause the device
to start processing SIP messages. An example of an affected
configuration is as follows:

    dial-peer voice <Voice dial-peer tag> voip
     ...
    !

In addition to inspecting the Cisco IOS device configuration for a
dial-peer command that causes the device to process SIP messages,
administrators can also use the command show processes | include SIP
to determine whether Cisco IOS Software is running the processes that
handle SIP messages. In the following example, the presence of the
processes CCSIP_UDP_SOCKET or CCSIP_TCP_SOCKET indicates that the
Cisco IOS device is processing SIP messages:

        Router#show processes | include SIP
         149 Mwe 40F48254            4          1    400023108/24000  0 CCSIP_UDP_SOCKET
         150 Mwe 40F48034            4          1    400023388/24000  0 CCSIP_TCP_SOCKET

warning Warning: Since there are several ways a device running Cisco
IOS Software can start processing SIP messages, it is recommended
that the "show processes | include SIP" command be used to determine
whether the device is processing SIP messages instead of relying on
the presence of specific configuration commands.

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the
show version command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the show version command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
    Cisco Internetwork Operating System Software
    IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by cisco Systems, Inc.
    Compiled Mon 17-Mar-08 14:39 by dchih
    
    
    !--- output truncated
    

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.4(20)T with an installed image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team
    
    
    !--- output truncated
    

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link:

http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+--------------------------------

The SIP Application Layer Gateway (ALG), which is used by the Cisco
IOS NAT and firewall features of Cisco IOS Software, is not affected
by this vulnerability. Cisco IOS XE Software and Cisco IOS XR
Software are not affected by this vulnerability. No other Cisco
products are currently known to be affected by this vulnerability.

Details
=======

SIP is a popular signaling protocol that is used to manage voice and
video calls across IP networks such as the Internet. SIP is
responsible for handling all aspects of call setup and termination.
Voice and video are the most popular types of sessions that SIP
handles, but the protocol has the flexibility to accommodate other
applications that require call setup and termination. SIP call
signaling can use UDP (port 5060), TCP (port 5060), or TLS (TCP port
5061) as the underlying transport protocol.

The Cisco Unified Border Element (previously known as the Cisco
Multiservice IP-to-IP Gateway) is a special Cisco IOS Software image
that runs on Cisco multiservice gateway platforms. It provides a
network-to-network interface point for billing, security, call
admission control, quality of service, and signaling interworking.

For more information about Cisco Unified Border Element refer to the
following link:

http://www.cisco.com/en/US/products/sw/voicesw/ps5640/index.html

A DoS vulnerability exists in the SIP implementation in Cisco IOS
Software when devices are running a Cisco IOS image that contains the
Cisco Unified Border Element feature. This vulnerability is triggered
by processing a series of crafted SIP messages.

This vulnerability is documented in Cisco Bug ID CSCsx25880 and has been
assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-2870.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss

CSCsx25880 - Crafted SIP packet may cause device reload

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability described in this
document may result in a reload of the device. The issue could be
repeatedly exploited to cause an extended DoS condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS Software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.0-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.1-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.2-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.2 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.3-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
| 12.3       | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3B      | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3BC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3BW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3EU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3T      | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3TPC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3VA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XI     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XS     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YH     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YI     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            | Releases prior to 12.3(11)YK3 are     | 12.4(20)T4   |
|            | vulnerable, release 12.3(11)YK3 and   |              |
| 12.3YK     | later are not vulnerable; first fixed | 12.4(22)T3   |
|            | in 12.4T                              |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.3YM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            | Vulnerable; first fixed in 12.4T      | 12.4(20)T4   |
|            |                                       |              |
| 12.3YS     | Releases up to and including 12.3(11) | 12.4(22)T3   |
|            | YS1 are not vulnerable.               |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YT     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.3YU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3ZA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|  Affected  |                                       | Recommended  |
| 12.4-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
| 12.4       | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4GC     | 12.4(24)GC1                           |              |
|------------+---------------------------------------+--------------|
| 12.4JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MR     | 12.4(19)MR3                           | 12.4(19)MR3  |
|------------+---------------------------------------+--------------|
| 12.4SW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            | 12.4(24)T1                            |              |
|            |                                       | 12.4(20)T4   |
|            | 12.4(15)T10                           |              |
| 12.4T      |                                       | 12.4(22)T3   |
|            | 12.4(20)T3                            |              |
|            |                                       | 12.4(24)T2;  |
|            | 12.4(22)T2                            | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XA     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XB     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XC     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XD     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XE     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XJ     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XL     | 12.4(15)XL5                           |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            | Vulnerable; first fixed in 12.4T      | 12.4(20)T4   |
|            |                                       |              |
| 12.4XM     | Releases up to and including 12.4(15) | 12.4(22)T3   |
|            | XM are not vulnerable.                |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4XN     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.4XP     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
| 12.4XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XT     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.4XV     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XW     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XY     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XZ     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4YA     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4YB     | 12.4(22)YB1                           | 12.4(22)YB4  |
|------------+---------------------------------------+--------------|
| 12.4YD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4YE     | Not Vulnerable                        |              |
+-------------------------------------------------------------------+

Note: No Cisco IOS-XE or Cisco IOS Software Modularity releases are
affected by this vulnerability.

Workarounds
===========

If the affected Cisco IOS device requires SIP for VoIP services, SIP
cannot be disabled, and therefore, no workarounds are available.
Users are advised to apply mitigation techniques to help limit
exposure to the vulnerability. Mitigation consists of allowing only
legitimate devices to connect to the routers. To increase
effectiveness, the mitigation must be coupled with anti-spoofing
measures on the network edge. This action is required because SIP can
use UDP as the transport protocol.

Additional mitigations that can be deployed on Cisco devices within
the network are available in the companion document "Cisco Applied
Mitigation Bulletin: Identifying and Mitigating Exploitation of the
Denial of Service Vulnerabilities in Cisco Unified Communications
Manager and Cisco IOS Software", which is available at the following
location:

http://www.cisco.com/warp/public/707/cisco-amb-20090923-voice.shtml

Disable SIP Listening Ports
+--------------------------

For devices that do not require SIP to be enabled, the simplest and
most effective workaround is to disable SIP processing on the device.
Some versions of Cisco IOS Software allow administrators to
accomplish this with the following commands:

    sip-ua
     no transport udp
     no transport tcp
     no transport tcp tls

Warning: When applying this workaround to devices that are
processing Media Gateway Control Protocol (MGCP) or H.323 calls, the
device will not stop SIP processing while active calls are being
processed. Under these circumstances, this workaround should be
implemented during a maintenance window when active calls can be
briefly stopped.

The "show udp connections", "show tcp brief all", and "show processes |
include SIP" commands can be used to confirm that the SIP UDP and TCP
ports are closed after applying this workaround.

Depending on the Cisco IOS Software version in use, the output of
"show ip sockets" still showed UDP port 5060 open, but sending
something to that port caused the SIP process to emit the following
message:

    *Feb  2 11:36:47.691: sip_udp_sock_process_read: SIP UDP Listener is
    DISABLED 

Control Plane Policing
+---------------------

For devices that need to offer SIP services it is possible to use
Control Plane Policing (CoPP) to block SIP traffic to the device from
untrusted sources. Cisco IOS Releases 12.0S, 12.2SX, 12.2S, 12.3T,
12.4, and 12.4T support the CoPP feature. CoPP may be configured on a
device to protect the management and control planes to minimize the
risk and effectiveness of direct infrastructure attacks by explicitly
permitting only authorized traffic sent to infrastructure devices in
accordance with existing security policies and configurations. The
following example can be adapted to the network

    
    !-- The 192.168.1.0/24 network and the 172.16.1.1 host are trusted.
    !-- Everything else is not trusted. The following access list is used
    !-- to determine what traffic needs to be dropped by a control plane
    !-- policy (the CoPP feature.) If the access list matches (permit)
    !-- then traffic will be dropped and if the access list does not
    !-- match (deny) then traffic will be processed by the router.
    
    
    access-list 100 deny udp 192.168.1.0 0.0.0.255 any eq 5060
    access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5060
    access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5061
    access-list 100 deny udp host 172.16.1.1 any eq 5060
    access-list 100 deny tcp host 172.16.1.1 any eq 5060
    access-list 100 deny tcp host 172.16.1.1 any eq 5061
    access-list 100 permit udp any any eq 5060
    access-list 100 permit tcp any any eq 5060
    access-list 100 permit tcp any any eq 5061
    
    
    !-- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4
    !-- traffic in accordance with existing security policies and
    !-- configurations for traffic that is authorized to be sent
    !-- to infrastructure devices.
    !-- Create a Class-Map for traffic to be policed by
    !-- the CoPP feature.
    
    
    class-map match-all drop-sip-class
      match access-group 100
    
    
    !-- Create a Policy-Map that will be applied to the
    !-- Control-Plane of the device.
    
    
    policy-map drop-sip-traffic
     class drop-sip-class
      drop
    
    
    !-- Apply the Policy-Map to the Control-Plane of the
    !-- device.
    
    
    control-plane
     service-policy input drop-sip-traffic

Warning: Because SIP can use UDP as a transport protocol, it
is possible to easily spoof the IP address of the sender, which may
defeat access control lists that permit communication to these ports
from trusted IP addresses.

In the above CoPP example, the access control entries (ACEs) that
match the potential exploit packets with the "permit" action result
in these packets being discarded by the policy-map "drop" function,
while packets that match the "deny" action (not shown) are not
affected by the policy-map drop function. Additional information on
the configuration and use of the CoPP feature can be found at:

http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html

and

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at:

http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html

or as otherwise set forth at Cisco.com Downloads at:

http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to:

http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html

for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was discovered during internal testing.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-sip.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+----------------------------------------+
| Revision |                   | Initial |
| 1.0      | 2009-September-23 | public  |
|          |                   | release |
+----------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and
registering to receive security information from Cisco, is available
on Cisco's worldwide website at:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

This includes instructions for press inquiries regarding Cisco security
notices. All Cisco security advisories are available at:

http://www.cisco.com/go/psirt
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukGZ86n/Gc8U/uARAh54AJ4jQJCLVMauxJXj00WMu822+kH1TQCfTzA6
2++Xtx6BvyycWfoy75Zjtx0=
=nUyE
-----END PGP SIGNATURE-----

From psirt at cisco.com  Wed Sep 23 12:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Crafted
	Encryption Packet Denial of Service Vulnerability
Message-ID: <200909231215.tls@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Crafted Encryption Packet
Denial of Service Vulnerability

Advisory ID: cisco-sa-20090923-tls

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

Cisco IOS? Software contains a vulnerability that could allow an
attacker to cause a Cisco IOS device to reload by remotely sending a
crafted encryption packet.

Cisco has released free software updates that address this
vulnerability.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-tls.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

Vulnerable Products
+------------------

Devices running affected versions of Cisco IOS Software are
susceptible if configured with any of the following features:

  * Secure Socket Layer (SSL) Virtual Private Network (VPN)
  * Secure Shell (SSH)
  * Internet Key Exchange (IKE) Encrypted Nonces

Note: Other SSL/HTTPS related features than WebVPN and SSL VPN are
not affected by this vulnerability.

To determine whether SSLVPN is enabled on a device, log in to the
device and issue the command-line interface (CLI) command "show
running-config | include webvpn". If the device returns any output
then SSLVPN is configured and the device may be vulnerable.
Vulnerable configurations vary depending on whether the device is
supporting Cisco IOS WebVPN (introduced in Release 12.3(14)T) or
Cisco IOS SSLVPNs (introduced in Release 12.4(6)T). The following
methods describe how to confirm if the device is vulnerable:

If the output from "show running-config | include webvpn" contains
"webvpn enable" then the device is configured with the original Cisco
IOS WebVPN. The only way to determine whether the device is
vulnerable is to examine the output of "show running-config" to
confirm that webvpn is enabled via the command "webvpn enable" and
that a "ssl trustpoint" has been configured. The following example
shows a vulnerable device configured with Cisco IOS WebVPN:

    webvpn enable
    !
    webvpn
     ssl trustpoint TP-self-signed-29742012

If the output from "show running-config | include webvpn" contains
"webvpn gateway <word>" then the device is supporting the Cisco IOS
SSLVPN feature. A device is vulnerable if it has the "inservice"
command in at least one of the "webvpn gateway" sections. The
following example shows a vulnerable device configured with Cisco IOS
SSLVPN:

    Router# show running | section webvpn        
    webvpn gateway Gateway
     ip address 10.1.1.1 port 443  
     ssl trustpoint Gateway-TP
     inservice
     !
    Router#

A device that supports the Cisco IOS SSLVPN is not vulnerable if it
has no "webvpn gateways" configured or all the configured "webvpn
gateways" contain the "no inservice" webvpn gateway command.

To determine if SSH is enabled use the "show ip ssh" command, as shown
in the following example:

    Router#show ip ssh 
    SSH Enabled - version 1.99
    Authentication timeout: 120 secs; Authentication retries: 3
    Minimum expected Diffie Hellman key size : 1024 bits

To determine if the IKE encrypted nonces feature is enabled, use the 
"show running-config | include rsa-encr" command as follows:

    Router#show running-config | inc rsa-encr
     authentication rsa-encr

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the
show version command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the show version command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
    Cisco Internetwork Operating System Software
    IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by cisco Systems, Inc.
    Compiled Mon 17-Mar-08 14:39 by dchih
    
    
    !--- output truncated
    

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.4(20)T with an installed image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team
    
    
    !--- output truncated
    

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link:

http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+--------------------------------

The Cisco ASA 5500 Series Adaptive Security Appliances are not
affected by this vulnerability.

Cisco IOS XR Software is not affected by this vulnerability.

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

A Cisco IOS device that is configured for SSLVPN or SSH may reload
when it receives a specially crafted TCP packet on TCP port 443
(SSLVPN) or TCP port 22 (SSH). Completion of the three-way handshake
to the associated TCP port number of these features is required for
the vulnerability to be successfully exploited; however,
authentication is not required. A Cisco IOS device that is configured
for IKE encrypted nonces may reload when it receives a specially
crafted UDP packet on port 500 or 4500 (if configured for NAT
Traversal (NAT-T)).

This vulnerability is documented in Cisco bug ID CSCsq24002 and has
been assigned the Common Vulnerabilities and Exposures (CVE) identifier
CVE-2009-2871.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss

CSCsq24002 - Crafted Encrypted packet may cause device reload

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability described in this
document may result in a reload of the device. The issue could be
repeatedly exploited to cause an extended DoS condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
|  Affected  |                                        | Recommended |
| 12.0-Based |          First Fixed Release           |   Release   |
|  Releases  |                                        |             |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                        | Recommended |
| 12.1-Based |          First Fixed Release           |   Release   |
|  Releases  |                                        |             |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                        | Recommended |
| 12.2-Based |          First Fixed Release           |   Release   |
|  Releases  |                                        |             |
|------------+----------------------------------------+-------------|
| 12.2       | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2B      | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2BC     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2BW     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2BX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2BY     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2BZ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2CX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2CY     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2CZ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2DA     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2DD     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2DX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2EW     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2EWA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2EX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2EY     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2EZ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2FX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2FY     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2FZ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IRA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IRB    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IRC    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IXA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IXB    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IXC    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IXD    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IXE    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IXF    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IXG    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IXH    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2JA     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2JK     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2MB     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2MC     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2S      | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SB     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SBC    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SCA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SCB    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SE     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SEA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SEB    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SEC    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SED    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SEE    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SEF    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SEG    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SG     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SGA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SL     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SM     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SO     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SQ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SRA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SRB    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SRC    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SRD    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2STE    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SU     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SV     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SVA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SVC    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SVD    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SVE    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SW     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SXA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SXB    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SXD    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SXE    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SXF    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SXH    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SXI    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SY     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SZ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2T      | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2TPC    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XA     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XB     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XC     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XD     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XE     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XF     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XG     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XH     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XI     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XJ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XK     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XL     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XM     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XNA    | Please see Cisco IOS-XE Software       |             |
|            | Availability                           |             |
|------------+----------------------------------------+-------------|
| 12.2XNB    | Please see Cisco IOS-XE Software       |             |
|            | Availability                           |             |
|------------+----------------------------------------+-------------|
| 12.2XNC    | Please see Cisco IOS-XE Software       |             |
|            | Availability                           |             |
|------------+----------------------------------------+-------------|
| 12.2XND    | Please see Cisco IOS-XE Software       |             |
|            | Availability                           |             |
|------------+----------------------------------------+-------------|
| 12.2XO     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XQ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XR     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XS     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XT     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XU     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XV     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XW     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YA     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YB     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YC     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YD     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YE     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YF     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YG     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YH     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YJ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YK     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YL     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YM     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YN     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YO     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YP     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YQ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YR     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YS     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YT     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YU     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YV     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YW     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YY     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YZ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZA     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZB     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZC     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZD     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZE     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZF     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZG     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZH     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZJ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZL     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZP     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZU     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZY     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZYA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
|  Affected  |                                        | Recommended |
| 12.3-Based |          First Fixed Release           |   Release   |
|  Releases  |                                        |             |
|-------------------------------------------------------------------|
| There are no affected 12.3 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                        | Recommended |
| 12.4-Based |          First Fixed Release           |   Release   |
|  Releases  |                                        |             |
|------------+----------------------------------------+-------------|
| 12.4       | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4GC     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JA     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JDA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JDC    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JDD    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JK     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JL     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JMA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JMB    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4MD     | 12.4(15)MD3                            | 12.4(15)MD3 |
|------------+----------------------------------------+-------------|
| 12.4MDA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4MR     | 12.4(19)MR3                            | 12.4(19)MR3 |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)T10 |
| 12.4SW     | Vulnerable; first fixed in 12.4T       |             |
|            |                                        | 12.4(20)T4  |
|------------+----------------------------------------+-------------|
|            | 12.4(22)T2                             |             |
|            |                                        | 12.4(15)T10 |
| 12.4T      | 12.4(20)T3                             |             |
|            |                                        | 12.4(20)T4  |
|            | 12.4(24)T                              |             |
|------------+----------------------------------------+-------------|
| 12.4XA     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4XB     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4XC     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4XD     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4XE     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)T10 |
| 12.4XF     | Vulnerable; first fixed in 12.4T       |             |
|            |                                        | 12.4(20)T4  |
|------------+----------------------------------------+-------------|
| 12.4XG     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)T10 |
| 12.4XJ     | Vulnerable; first fixed in 12.4T       |             |
|            |                                        | 12.4(20)T4  |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)T10 |
| 12.4XK     | Vulnerable; first fixed in 12.4T       |             |
|            |                                        | 12.4(20)T4  |
|------------+----------------------------------------+-------------|
| 12.4XL     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4XM     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4XN     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4XP     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4XQ     | 12.4(15)XQ3                            | 12.4(15)T10 |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)XR7 |
| 12.4XR     | 12.4(15)XR5                            |             |
|            |                                        | 12.4(22)XR  |
|------------+----------------------------------------+-------------|
| 12.4XT     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
|            | Vulnerable; Contact your support       |             |
| 12.4XV     | organization per the instructions in   |             |
|            | Obtaining Fixed Software section of    |             |
|            | this advisory                          |             |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)T10 |
| 12.4XW     | Vulnerable; first fixed in 12.4T       |             |
|            |                                        | 12.4(20)T4  |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)T10 |
| 12.4XY     | Vulnerable; first fixed in 12.4T       |             |
|            |                                        | 12.4(20)T4  |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)T10 |
| 12.4XZ     | Vulnerable; first fixed in 12.4T       |             |
|            |                                        | 12.4(20)T4  |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)T10 |
| 12.4YA     | Vulnerable; first fixed in 12.4T       |             |
|            |                                        | 12.4(20)T4  |
|------------+----------------------------------------+-------------|
| 12.4YB     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4YD     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4YE     | Not Vulnerable                         |             |
+-------------------------------------------------------------------+

Note: No Cisco IOS Software Modularity releases are affected by this
vulnerability.

Cisco IOS XE Software

+-------------------------------------------------------------------+
|       IOS XE Release       |         First Fixed Release          |
|----------------------------+--------------------------------------|
| 2.1.x                      | Not Vulnerable                       |
|----------------------------+--------------------------------------|
| 2.2.x                      | Not Vulnerable                       |
|----------------------------+--------------------------------------|
| 2.3.x                      | 2.3.2                                |
|----------------------------+--------------------------------------|
| 2.4.x                      | Not Vulnerable                       |
+-------------------------------------------------------------------+

Workarounds
===========

There are no available workarounds other than disabling the affected
features and protecting SSH access with the use of VTY access control
lists.

Use the "no webvpn enable" command to disable SSL VPN use.

For Cisco IOS the SSH server can be disabled by applying the command 
"crypto key zeroize rsa" while in configuration mode. The SSH server is
enabled automatically upon generating an RSA key pair. Zeroing the
RSA keys is the only way to completely disable the SSH server.

Access to the SSH server on Cisco IOS Software may also be disabled
by removing SSH as a valid transport protocol. This action can be
done by reapplying the transport input command with 'ssh' removed
from the list of permitted transports on vty lines while in
configuration mode. For example:

    line vty 0 4                                                                    
          transport input telnet                                                        
        end

If SSH server functionality is desired, access to the server can be
restricted to specific source IP addresses or blocked entirely
through the use of Access Control Lists (ACLs) on the vty lines as
shown in the following URL:

http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/release/12.1_9_ea1/configuration/guide/swacl.html#xtocid14

More information on configuring ACLs can be found on Cisco's public
website:

http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00800a5b9a.shtml

The following is an example of a vty access-list:

    access-list 2 permit 10.1.1.0 0.0.0.255
    access-list 2 deny any
    
    line vty 0 4
     access-class 2 in

In the previous example, only the 10.1.1.0/24 network is allowed to
SSH to the Cisco IOS device.

To disable IKE encrypted nonces use the "no authentication rsa-encr"
command under an ISAKMP policy, as shown in the following example:

    crypto isakmp policy
     no authentication rsa-encr

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at:

http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html

or as otherwise set forth at Cisco.com Downloads at:

http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to:

http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html

for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was found during internal testing.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-tls.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+----------------------------------------+
| Revision |                   | Initial |
| 1.0      | 2009-September-23 | public  |
|          |                   | release |
+----------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and
registering to receive security information from Cisco, is available
on Cisco's worldwide website at:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

This includes instructions for press inquiries regarding Cisco security
notices. All Cisco security advisories are available at:

http://www.cisco.com/go/psirt
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukGd86n/Gc8U/uARAltxAJsHsWKROOB5Ph8mcFs+ZUIYygRoEgCePeZX
A9ezksakGzQynAYZbBjJ+uE=
=n8Uh
-----END PGP SIGNATURE-----

From psirt at cisco.com  Wed Sep 23 12:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: [c-nsp] Cisco Security Advisory: Cisco Unified Communications
	Manager Session Initiation Protocol Denial of Service Vulnerability
Message-ID: <200909231215.cm@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco Unified Communications Manager Session
Initiation Protocol Denial of Service Vulnerability

Advisory ID: cisco-sa-20090923-cm

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

Cisco Unified Communications Manager, which was formerly Cisco
Unified CallManager, contains a denial of service (DoS) vulnerability
in the Session Initiation Protocol (SIP) service. An exploit of this
vulnerability may cause an interruption in voice services.

Cisco has released free software updates that address this
vulnerability. There are no workarounds for this vulnerability.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-cm.shtml

Note: Cisco IOS? Software is also affected by the vulnerability
described in this advisory. A companion advisory for Cisco IOS
software is available at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-sip.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

The vulnerability described in this document applies to the Cisco
Unified Communications Manager.

Vulnerable Products
+------------------

The following Cisco Unified Communications Manager versions are
affected:

  * Cisco Unified Communications Manager 5.x versions prior to 5.1(3g)
  * Cisco Unified Communications Manager 6.x versions prior to 6.1(4)
  * Cisco Unified Communications Manager 7.0.x versions prior to 7.0(2a)su1
  * Cisco Unified Communications Manager 7.1.x versions prior to 7.1(2)

Cisco Unified CallManager versions 4.x are not affected by this
vulnerability. Administrators of systems that are running Cisco
Unified Communications Manager versions 5.x, 6.x and 7.x can
determine the software version by viewing the main page of the Cisco
Unified Communications Manager Administration interface. The software
version can also be determined by running the "show version active"
command via the command-line interface.

A SIP trunk must be configured for the Cisco Unified CallManager
server to begin listening for SIP messages on TCP and UDP port 5060
and TCP/5061. However, in Cisco Unified Communications Manager
versions 5.x and later, the use of SIP as a call signaling protocol
is enabled by default and cannot be disabled.

Cisco IOS Software is also affected by this vulnerability, but it is
associated with different Cisco bug IDs. A companion security
advisory for Cisco IOS Software is available at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-sip.shtml

Products Confirmed Not Vulnerable
+--------------------------------

Cisco Unified CallManager versions 4.x are not affected by this
vulnerability. With the exception of Cisco IOS software, no other
Cisco products are currently known to be affected by this
vulnerability.

Details
=======

Cisco Unified Communications Manager is the call processing component
of the Cisco IP Telephony solution that extends enterprise telephony
features and functions to packet telephony network devices, such as
IP phones, media processing devices, voice-over-IP gateways, and
multimedia applications.

SIP is a popular signaling protocol that manages voice and video
calls across IP networks such as the Internet. SIP is responsible for
handling all aspects of call setup and termination. Voice and video
are the most popular types of sessions that SIP handles, but the
protocol is flexible enough to accommodate other applications that
require call setup and termination. SIP call signaling can use UDP
(port 5060), TCP (port 5060), or Transport Layer Security (TLS; TCP
port 5061) as the underlying transport protocol.

A DoS vulnerability exists in the SIP implementation of the Cisco
Unified Communications Manager. This vulnerability could be triggered
when Cisco Unified Communications Manager processes crafted SIP
messages. An exploit could lead to a reload of the main Cisco Unified
Communications Manager process.

This vulnerability is documented in Cisco bug ID CSCsz95423 and has been
assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-2864.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss

CSCsz95423 - Crafted SIP packet may cause CM process to crash

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability that is described in
this advisory could result in a reload of the Cisco Unified
Communications Manager process, which may result in the interruption
of voice services.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

The following table contains the first fixed software release for
this vulnerability. A device running a version of the given release
in a specific row (less than the First Fixed Release) is known to be
vulnerable.

+---------------------------------------+
| Release   | First Fixed Version       |
|-----------+---------------------------|
| 4.x       | Not Vulnerable            |
|-----------+---------------------------|
| 5.x       | 5.1(3g)                   |
|-----------+---------------------------|
| 6.x       | 6.1(4)                    |
|-----------+---------------------------|
| 7.0.x     | 7.0(2a)su1                |
|-----------+---------------------------|
| 7.1.x     | 7.1(2)                    |
+---------------------------------------+

Workarounds
===========

There are no workarounds for this vulnerability.

It is possible to mitigate this vulnerability by implementing
filtering on screening devices and permitting TCP/UDP access to ports
5060 and TCP/5061 only from networks that require SIP access to Cisco
Unified Communications Manager servers.

If Cisco Unified Communications Manager does not need to provide SIP
services, administrators can configure the Cisco Unified
Communications Manager to listen for SIP messages on non standard
ports. Use the following instructions to change the ports from their
default values:

Step 1 Log into the Cisco Unified CallManager Administration web
interface.

Step 2 Navigate to System > Cisco Unified CM and locate the
appropriate Cisco Unified Communications Manager.

Step 3 Change the fields SIP Phone Port and SIP Phone Secure Port
fields to a non standard port and click Save.

SIP Phone Port, which is 5060 by default, refers to the TCP and UDP
ports where the Cisco Unified Communications Manager listens for
normal SIP messages, and SIP Phone Secure Port, by default 5061,
refers to the TCP port where the Cisco Unified Communications Manager
listens for SIP over TLS messages. For additional information about
this procedure, refer to the "Updating a Cisco Unified Communications
Manager" section of the "Cisco Unified Communications Manager
Administration Guide" at:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/admin/7_0_1/ccmcfg/b02ccm.html#wp1057513

Note: For a SIP port change to take effect, the Cisco CallManager
Service must be restarted. For information on how to restart the
service, refer to the "Restarting the Cisco CallManager Service"
section of the document at:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/admin/7_0_1/ccmcfg/b03dpi.html#wp1075124

Additional mitigations that can be deployed on Cisco devices in the
network are available in the companion document "Cisco Applied
Mitigation Bulletin: Identifying and Mitigating Exploitation of the
Denial of Service Vulnerabilities in Cisco Unified Communications
Manager and Cisco IOS Software", which is available at the following
location:

http://www.cisco.com/warp/public/707/cisco-amb-20090923-voice.shtml

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at:

http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html

or as otherwise set forth at Cisco.com Downloads at:

http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to:

http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html

for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was discovered during internal testing.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-cm.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+----------------------------------------+
| Revision |                   | Initial |
| 1.0      | 2009-September-23 | public  |
|          |                   | release |
+----------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and
registering to receive security information from Cisco, is available
on Cisco's worldwide website at:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

This includes instructions for press inquiries regarding Cisco security
notices. All Cisco security advisories are available at:

http://www.cisco.com/go/psirt
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukGE86n/Gc8U/uARAp0sAJ9WOsbXB1KzPl36kQRFCcVHLqC9twCgiOQx
lBVMS0I0ypD4TW2DBvWPkLM=
=1qvW
-----END PGP SIGNATURE-----

From psirt at cisco.com  Wed Sep 23 12:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Authentication
	Proxy Vulnerability
Message-ID: <200909231215.auth-proxy@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Authentication Proxy
Vulnerability

Advisory ID: cisco-sa-20090923-auth-proxy

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

Cisco IOS? Software configured with Authentication Proxy for HTTP(S),
Web Authentication or the consent feature, contains a vulnerability
that may allow an unauthenticated session to bypass the
authentication proxy server or bypass the consent webpage.

Cisco has released free software updates that address this
vulnerability.

There are no workarounds that mitigate this vulnerability.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-auth-proxy.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

Vulnerable Products
+------------------

Devices running affected versions of Cisco IOS Software and
configured with Authentication Proxy for HTTP(S) or Web
Authentication or the consent feature are vulnerable.

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the 
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
     Cisco Internetwork Operating System Software
     IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
     Technical Support: http://www.cisco.com/techsupport
     Copyright ?) 1986-2008 by cisco Systems, Inc.
     Compiled Mon 17-Mar-08 14:39 by dchih
    
     <output truncated>

The following example shows a product that is running Cisco IOS
Software release 12.4(20)T with an image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright ?) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team
    
    <output truncated>

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link: http://www.cisco.com/warp/public/620/1.html.

To determine if your device is configured with either Authentication
Proxy for HTTP(S), Web Authentication or the consent feature, log
into the device and issue the "show running-config" command.

The following example identifies firewall authentication proxy
services using the ip auth-proxy under the proxy rule name
example_auth_proxy_name:

    Router#show running-config
    <output truncated>
    
     !
     ! Set up the aaa new model to use the authentication proxy.
     !
    
     aaa authorization auth-proxy default group
    
     !
     ! Apply a name to the authentication proxy configuration rule.
     !
    
     ip auth-proxy name example_auth_proxy_name http
    
     !
     ! Apply the authentication proxy rule at an interface.
     !
    
     interface e0 
      ip auth-proxy example_auth_proxy_name
    
     !
    
    <output truncated>

The following example identifies firewall authentication proxy
services running for HTTP under the proxy rule name
example_auth_proxy_name, using the ip admission commands. This is the
same configuration as Web Authentication:

    Router#show running-config
    <output truncated>
    
     !
     ! Set up the aaa new model to use the authentication proxy.
     !
    
     aaa authorization auth-proxy default group
    
     !
     ! Apply a name to the authentication proxy configuration rule.
     !
    
     ip admission name example_auth_proxy_name proxy http inactivity-time 60
    
     !
     ! Apply the authentication proxy rule at an interface.
     !
    
     interface FastEthernet0/1
      ip admission example_auth_proxy_name
    
     !
    
     <output truncated>

The following example identifies a device configured with the consent
feature under the consent rule name example_consent_rule:

    Router#show running-config
    <output truncated>
    
     !
     ! Apply a name to the consent configuration rule.
     !
    
     ip admission name example_consent_rule consent
    
     !
     ! Apply the consent rule at an interface.
     !
    
     interface FastEthernet 0/0 
      ip admission consent-rule_rule
    
     !
    
    <output truncated>

Products Confirmed Not Vulnerable
+--------------------------------

The following products and features are not affected by this
vulnerability:

  * Cisco IOS XR Software
  * Cisco IOS XE Software
  * Firewall Authentication Proxy for FTP and Telnet Sessions
  * Cisco IOS devices not configured with Authentication Proxy for
    HTTP(S) or the consent feature

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

The Cisco IOS Firewall authentication proxy feature allows network
administrators to apply specific security policies on a per-user
basis. With the authentication proxy feature, users can log in to the
network or access the Internet via HTTP, and their specific access
profiles are automatically retrieved and applied from a CiscoSecure
ACS, or other RADIUS or TACACS+ authentication server. The user
profiles are active only when there is active traffic from the
authenticated users. Web Authentication feature leverages the
underlying authentication proxy feature.

The consent feature for Cisco IOS routers enables organizations to
provide temporary Internet and corporate access to end users through
their wired and wireless networks by presenting a consent webpage.
The consent feature can be used with or without requesting a username
and password, but still leverages the underlying authentication proxy
feature.

This vulnerability allows a session to be permitted without first
being authenticated by the authentication proxy, or to be permitted
without first acknowledging the consent webpage. At least one
successfully authenticated session or accepted consent session must
exist for the vulnerability to be exposed. When this occurs, the
RADIUS or TACACS+ server will show subsequent users as authenticated,
all with the same username as the initial connection if performing
authentication, regardless of the authentication information provided
by the user and whether it was defined on the AAA server, and
regardless of whether the password was correct.

This vulnerability is caused by a race condition in the code, and
several conditions outside the control of a malicious user and must
be met before this vulnerability could be exploited.

For further information on Authentication Proxy for HTTP see the
Cisco IOS Security Configuration Guide, Release 12.4 "Configuring
Authentication Proxy" at the following link:

http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_cfg_authen_prxy_external_docbase_0900e4b1805afd05_4container_external_docbase_0900e4b1807b01d5.html

For further information on Authentication Proxy for HTTPS see the
Cisco IOS Security Configuration Guide, Release 12.4 "Firewall
Support of HTTPS Authentication Proxy" at the following link:

http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_fwall_https_prxy_external_docbase_0900e4b1805afe18_4container_external_docbase_0900e4b1807b01d5.html

For further information on the consent feature see the Cisco IOS
Security Configuration Guide, Securing User Services, Release 12.2SR
"Consent Feature for Cisco IOS Routers" at the following link:

http://www.cisco.com/en/US/docs/ios/sec_user_services/configuration/guide/sec_cons_feat_rtrs_ps6922_TSD_Products_Configuration_Guide_Chapter.html

For further information on the Web Authentication feature see the
Catalyst 3750 Switch Software Configuration Guide, Release 12.2(50)SE
"Configuring IEEE 802.1x Port-Based Authentication" at the following
link:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_50_se/configuration/guide/sw8021x.html#wp1401291

This vulnerability is documented in the following Cisco Bug ID: 
CSCsy15227 and has been assigned the Common Vulnerabilities and Exposures
(CVE) identifier CVE-2009-2863.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss

CSCsy15227 - Cisco IOS Software Authentication Proxy Vulnerability

CVSS Base Score - 7.1

Access Vector           - Network
Access Complexity       - Medium
Authentication          - None
Confidentiality Impact  - Complete
Integrity Impact        - None
Availability Impact     - None

CVSS Temporal Score - 5.9

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed


Impact
======

Successful exploitation of the vulnerability may result in an
unauthenticated and unauthorized user bypassing the authentication
proxy services offered in Cisco IOS Authentication Proxy for HTTP(S)
and/or bypassing the consent accept webpage.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS Software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerability at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
|  Affected  |                                      |  Recommended  |
| 12.0-Based |         First Fixed Release          |    Release    |
|  Releases  |                                      |               |
|------------+--------------------------------------+---------------|
| 12.0       | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0DA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Releases up to and including 12.0(4) |               |
|            | DB are not vulnerable.               | 12.4(23b)     |
| 12.0DB     |                                      |               |
|            | Releases 12.0(7)DB and later are not | 12.4(25b)     |
|            | vulnerable; first fixed in 12.4      |               |
|------------+--------------------------------------+---------------|
|            | Releases up to and including 12.0(3) |               |
|            | DC1 are not vulnerable.              | 12.4(23b)     |
| 12.0DC     |                                      |               |
|            | Releases 12.0(7)DC and later are not | 12.4(25b)     |
|            | vulnerable; first fixed in 12.4      |               |
|------------+--------------------------------------+---------------|
| 12.0S      | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0SC     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0SL     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0SP     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0ST     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0SX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0SY     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0SZ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.4      | 12.4(23b)     |
| 12.0T      |                                      |               |
|            | Releases up to and including 12.0(4) | 12.4(25b)     |
|            | T1 are not vulnerable.               |               |
|------------+--------------------------------------+---------------|
| 12.0W      | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.0(5)WC4 are     |               |
| 12.0WC     | vulnerable, release 12.0(5)WC4 and   |               |
|            | later are not vulnerable             |               |
|------------+--------------------------------------+---------------|
| 12.0WT     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0XA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0XB     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0XC     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0XD     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.4      | 12.4(23b)     |
| 12.0XE     |                                      |               |
|            | Releases up to and including 12.0(5) | 12.4(25b)     |
|            | XE are not vulnerable.               |               |
|------------+--------------------------------------+---------------|
| 12.0XF     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0XG     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0XH     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0XI     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0XJ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.0XK     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.0XL     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0XM     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0XN     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0XQ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.4      | 12.4(23b)     |
| 12.0XR     |                                      |               |
|            | Releases up to and including 12.0(6) | 12.4(25b)     |
|            | XR are not vulnerable.               |               |
|------------+--------------------------------------+---------------|
| 12.0XS     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0XT     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.0XV     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|  Affected  |                                      |  Recommended  |
| 12.1-Based |         First Fixed Release          |    Release    |
|  Releases  |                                      |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.1       | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.1AA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1AX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Releases up to and including 12.1    | 12.2(50)SE3   |
|            | (13)AY are not vulnerable.           |               |
| 12.1AY     |                                      | 12.2(52)SE;   |
|            | Releases 12.1(22)AY1 and later are   | Available on  |
|            | not vulnerable; first fixed in       | 13-OCT-2009   |
|            | 12.2SE                               |               |
|------------+--------------------------------------+---------------|
| 12.1AZ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1CX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1DA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Releases up to and including 12.1(3) |               |
|            | DB1 are not vulnerable.              | 12.4(23b)     |
| 12.1DB     |                                      |               |
|            | Releases 12.1(4)DB1 and later are    | 12.4(25b)     |
|            | not vulnerable; first fixed in 12.4  |               |
|------------+--------------------------------------+---------------|
|            | Releases up to and including 12.1(4) |               |
|            | DC are not vulnerable.               | 12.4(23b)     |
| 12.1DC     |                                      |               |
|            | Releases 12.1(4)DC2 and later are    | 12.4(25b)     |
|            | not vulnerable; first fixed in 12.4  |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.1E      | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Releases up to and including 12.1(6) |               |
|            | EA1a are not vulnerable.             | 12.2(50)SE3;  |
| 12.1EA     |                                      | Available on  |
|            | Releases 12.1(8)EA1c and later are   | 13-OCT-2009   |
|            | not vulnerable; first fixed in       |               |
|            | 12.2SE                               |               |
|------------+--------------------------------------+---------------|
| 12.1EB     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1EC     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1EO     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1EU     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1EV     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1EW     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.4      | 12.4(23b)     |
| 12.1EX     |                                      |               |
|            | Releases up to and including 12.1(2) | 12.4(25b)     |
|            | EX are not vulnerable.               |               |
|------------+--------------------------------------+---------------|
| 12.1EY     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1EZ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1GA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1GB     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.1T      | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.1XA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1XB     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.1XC     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.1XD     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1XE     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1XF     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1XG     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.1XH     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.1XI     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.1XJ     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.1(3a)XL2 are    | 12.4(23b)     |
| 12.1XL     | vulnerable, release 12.1(3a)XL2 and  |               |
|            | later are not vulnerable; first      | 12.4(25b)     |
|            | fixed in 12.4                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.1XM     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.1XP     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.1XQ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.1XR     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.1XS     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.4      | 12.4(23b)     |
| 12.1XT     |                                      |               |
|            | Releases up to and including 12.1(2) | 12.4(25b)     |
|            | XT2 are not vulnerable.              |               |
|------------+--------------------------------------+---------------|
| 12.1XU     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1XV     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1XW     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1XX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1XY     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1XZ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.1YA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.4      | 12.4(23b)     |
| 12.1YB     |                                      |               |
|            | Releases up to and including 12.1(5) | 12.4(25b)     |
|            | YB are not vulnerable.               |               |
|------------+--------------------------------------+---------------|
| 12.1YC     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.1YD     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.1(5)YE6 are     | 12.4(23b)     |
| 12.1YE     | vulnerable, release 12.1(5)YE6 and   |               |
|            | later are not vulnerable; first      | 12.4(25b)     |
|            | fixed in 12.4                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.1YF     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.1YH     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.1YI     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.1YJ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|  Affected  |                                      |  Recommended  |
| 12.2-Based |         First Fixed Release          |    Release    |
|  Releases  |                                      |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2       | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.4      | 12.4(23b)     |
| 12.2B      |                                      |               |
|            | Releases up to and including 12.2(2) | 12.4(25b)     |
|            | B7 are not vulnerable.               |               |
|------------+--------------------------------------+---------------|
| 12.2BC     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2BW     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.2BX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2BY     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2BZ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2CX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2CY     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; migrate to any release   | 12.2(31)SB16  |
| 12.2CZ     | in 12.2SB                            |               |
|            |                                      | 12.2(33)SB7   |
|------------+--------------------------------------+---------------|
| 12.2DA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2DD     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.2DX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2EW     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2EWA    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.2SE    | 12.2(50)SE3   |
|            |                                      |               |
| 12.2EX     | Releases up to and including 12.2    | 12.2(52)SE;   |
|            | (37)EX are not vulnerable.           | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.2SE    | 12.2(50)SE3   |
|            |                                      |               |
| 12.2EY     | Releases up to and including 12.2    | 12.2(52)SE;   |
|            | (25)EY4 are not vulnerable.          | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
| 12.2EZ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2FX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2FY     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(50)SE3   |
|            |                                      |               |
| 12.2FZ     | Vulnerable; first fixed in 12.2SE    | 12.2(52)SE;   |
|            |                                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
| 12.2IRA    | Vulnerable; first fixed in 12.2SRD   | 12.2(33)SRD3  |
|------------+--------------------------------------+---------------|
| 12.2IRB    | Vulnerable; first fixed in 12.2SRD   | 12.2(33)SRD3  |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IRC    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IXA    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IXB    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IXC    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IXD    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IXE    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IXF    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IXG    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IXH    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.2JA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2JK     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2MB     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2MC     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Note: Releases prior to 12.2(30)S    | 12.2(31)SB16  |
| 12.2S      | are vulnerable, release 12.2(30)S    |               |
|            | and later are not vulnerable;        | 12.2(33)SB7   |
|------------+--------------------------------------+---------------|
| 12.2SB     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Note: Releases prior to 12.2(27)SBC3 | 12.2(31)SB16  |
| 12.2SBC    | are vulnerable, release 12.2(27)SBC3 |               |
|            | and later are not vulnerable;        | 12.2(33)SB7   |
|------------+--------------------------------------+---------------|
| 12.2SCA    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2SCB    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(50)SE3   |
|            | 12.2(50)SE3                          |               |
| 12.2SE     |                                      | 12.2(52)SE;   |
|            | 12.2(52)SE; Available on 13-OCT-2009 | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
| 12.2SEA    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2SEB    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(50)SE3   |
|            |                                      |               |
| 12.2SEC    | Vulnerable; first fixed in 12.2SE    | 12.2(52)SE;   |
|            |                                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(50)SE3   |
|            |                                      |               |
| 12.2SED    | Vulnerable; first fixed in 12.2SE    | 12.2(52)SE;   |
|            |                                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(50)SE3   |
|            |                                      |               |
| 12.2SEE    | Vulnerable; first fixed in 12.2SE    | 12.2(52)SE;   |
|            |                                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.2(25)SEF2 are   | 12.2(50)SE3   |
|            | vulnerable, release 12.2(25)SEF2 and |               |
| 12.2SEF    | later are not vulnerable; first      | 12.2(52)SE;   |
|            | fixed in 12.2SE                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.2(25)SEG4 are   | 12.2(50)SE3   |
|            | vulnerable, release 12.2(25)SEG4 and |               |
| 12.2SEG    | later are not vulnerable; first      | 12.2(52)SE;   |
|            | fixed in 12.2SE                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            | 12.2(50)SG4                          |               |
| 12.2SG     |                                      | 12.2(50)SG4   |
|            | 12.2(53)SG1; Available on            |               |
|            | 07-DEC-2009                          |               |
|------------+--------------------------------------+---------------|
| 12.2SGA    | 12.2(31)SGA11                        | 12.2(31)SGA11 |
|------------+--------------------------------------+---------------|
| 12.2SL     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2SM     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2SO     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2SQ     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.2SRA    | Vulnerable; first fixed in 12.2SRD   | 12.2(33)SRD3  |
|------------+--------------------------------------+---------------|
| 12.2SRB    | Vulnerable; first fixed in 12.2SRD   | 12.2(33)SRD3  |
|------------+--------------------------------------+---------------|
| 12.2SRC    | 12.2(33)SRC5; Available on           | 12.2(33)SRD3  |
|            | 29-OCT-2009                          |               |
|------------+--------------------------------------+---------------|
|            | 12.2(33)SRD2a                        |               |
| 12.2SRD    |                                      | 12.2(33)SRD3  |
|            | 12.2(33)SRD3                         |               |
|------------+--------------------------------------+---------------|
| 12.2STE    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2SU     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.2SV     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2SVA    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2SVC    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2SVD    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2SVE    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2SW     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2SX     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2SXA    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2SXB    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2SXD    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2SXE    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | 12.2(18)SXF17; Available on          | 12.2(18)      |
|            | 30-SEP-2009                          | SXF17;        |
| 12.2SXF    |                                      | Available on  |
|            | Please see IOS Software Modularity   | 30-SEP-2009   |
|            | Patch                                |               |
|------------+--------------------------------------+---------------|
|            | 12.2(33)SXH6; Available on           |               |
|            | 30-OCT-2009                          | 12.2(33)SXH6; |
| 12.2SXH    |                                      | Available on  |
|            | Please see IOS Software Modularity   | 30-OCT-2009   |
|            | Patch                                |               |
|------------+--------------------------------------+---------------|
|            | 12.2(33)SXI2                         |               |
| 12.2SXI    |                                      | 12.2(33)SXI2a |
|            | 12.2(33)SXI2a                        |               |
|------------+--------------------------------------+---------------|
| 12.2SY     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2SZ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2T      | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2TPC    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.4      | 12.4(23b)     |
| 12.2XA     |                                      |               |
|            | Releases up to and including 12.2(1) | 12.4(25b)     |
|            | XA are not vulnerable.               |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.4      | 12.4(23b)     |
| 12.2XB     |                                      |               |
|            | Releases up to and including 12.2(2) | 12.4(25b)     |
|            | XB1 are not vulnerable.              |               |
|------------+--------------------------------------+---------------|
| 12.2XC     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2XD     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.2XE     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2XF     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2XG     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2XH     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.2XI     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2XJ     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2XK     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2XL     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2XM     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.2XNA    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2XNB    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2XNC    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2XND    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(31)SGA11 |
| 12.2XO     | Vulnerable; first fixed in 12.2SG    |               |
|            |                                      | 12.2(50)SG4   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2XQ     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.2XR     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2XS     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2XT     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.2XU     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2XV     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2XW     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.2(4)YA8 are     | 12.4(23b)     |
| 12.2YA     | vulnerable, release 12.2(4)YA8 and   |               |
|            | later are not vulnerable; first      | 12.4(25b)     |
|            | fixed in 12.4                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YB     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YC     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.2YD     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YE     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YF     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.2YG     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YH     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YJ     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.2YK     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YL     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2YM     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YN     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YO     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.2YP     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YQ     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YR     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.2YS     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2YT     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YU     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.2(11)YV1 are    |               |
| 12.2YV     | vulnerable, release 12.2(11)YV1 and  |               |
|            | later are not vulnerable             |               |
|------------+--------------------------------------+---------------|
| 12.2YW     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YX     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.2YY     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YZ     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.2ZA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2ZB     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2ZC     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2ZD     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2ZE     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2ZF     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.2ZG     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.2(13)ZH6 are    | 12.4(23b)     |
| 12.2ZH     | vulnerable, release 12.2(13)ZH6 and  |               |
|            | later are not vulnerable; first      | 12.4(25b)     |
|            | fixed in 12.4                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2ZJ     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2ZL     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.2ZP     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(33)SXH6; |
| 12.2ZU     | Vulnerable; first fixed in 12.2SXH   | Available on  |
|            |                                      | 30-OCT-2009   |
|------------+--------------------------------------+---------------|
| 12.2ZX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2ZY     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2ZYA    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|  Affected  |                                      |  Recommended  |
| 12.3-Based |         First Fixed Release          |    Release    |
|  Releases  |                                      |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.3       | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.3B      | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.3BC     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3BW     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3EU     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JEA    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JEB    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JEC    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Releases up to and including 12.3(2) |               |
|            | JK3 are not vulnerable.              | 12.4(23b)     |
| 12.3JK     |                                      |               |
|            | Releases 12.3(8)JK1 and later are    | 12.4(25b)     |
|            | not vulnerable; first fixed in 12.4  |               |
|------------+--------------------------------------+---------------|
| 12.3JL     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.3T      | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.3TPC    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3VA     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.3XA     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.3XB     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.3(2)XC4 are     | 12.4(23b)     |
| 12.3XC     | vulnerable, release 12.3(2)XC4 and   |               |
|            | later are not vulnerable; first      | 12.4(25b)     |
|            | fixed in 12.4                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.3XD     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.3XE     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.3XF     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.3XG     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.3XI     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XJ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.3XK     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
|            |                                      | 12.4(22)T3    |
| 12.3XL     | Vulnerable; first fixed in 12.4T     |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.3XQ     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.3XR     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.3XS     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.3XU     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XW     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.3XX     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.3XY     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XZ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(23b)     |
| 12.3YA     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(25b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YD     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
| 12.3YF     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YG     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YH     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YI     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
| 12.3YJ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YK     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YM     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
| 12.3YQ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YS     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YT     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
| 12.3YU     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3YX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.3YZ     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3ZA     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|  Affected  |                                      |  Recommended  |
| 12.4-Based |         First Fixed Release          |    Release    |
|  Releases  |                                      |               |
|------------+--------------------------------------+---------------|
|            | 12.4(23a)                            | 12.4(23b)     |
| 12.4       |                                      |               |
|            | 12.4(25a)                            | 12.4(25b)     |
|------------+--------------------------------------+---------------|
| 12.4GC     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JDA    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JDC    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JDD    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JK     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JL     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JMA    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JMB    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4MD     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4MDA    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.4(19)MR1 are    |               |
| 12.4MR     | vulnerable, release 12.4(19)MR1 and  |               |
|            | later are not vulnerable             |               |
|------------+--------------------------------------+---------------|
| 12.4SW     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            | 12.4(24)T1                           |               |
|            |                                      | 12.4(20)T4    |
|            | 12.4(20)T3                           |               |
| 12.4T      |                                      | 12.4(22)T3    |
|            | 12.4(22)T2                           |               |
|            |                                      | 12.4(24)T2;   |
|            | 12.4(15)T9                           | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XA     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
| 12.4XB     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XC     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XD     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XE     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XF     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
| 12.4XG     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XJ     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XK     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
| 12.4XL     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4XM     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4XN     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4XP     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4XQ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4XR     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XT     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.4XV     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XW     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XY     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XZ     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4YA     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
| 12.4YB     | 12.4(22)YB4                          | 12.4(22)YB4   |
|------------+--------------------------------------+---------------|
| 12.4YD     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4YE     | Not Vulnerable                       |               |
+-------------------------------------------------------------------+

Cisco IOS Software Modularity - Maintenance Packs
+------------------------------------------------

Customers who are using Cisco IOS Software Modularity can apply the
respective maintenance packs. More information on Cisco IOS Software
Modularity can be found at the following link:

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_bulletin0900aecd80313e15.html

The Maintenance Packs listed below can be downloaded at:

http://www.cisco.com/go/pn

Cisco IOS Software Modularity Maintenance Pack for 12.2SXF
+---------------------------------------------------------

+-------------------------------------------------------------------+
|  Cisco IOS Software Release   |   Solution Maintenance Pack(MP)   |
|-------------------------------+-----------------------------------|
| 12.2(18)SXF11                 | MP002                             |
|-------------------------------+-----------------------------------|
| 12.2(18)SXF13                 | MP001                             |
|-------------------------------+-----------------------------------|
| 12.2(18)SXF14                 | MP001                             |
|-------------------------------+-----------------------------------|
| 12.2(18)SXF15                 | MP001                             |
|-------------------------------+-----------------------------------|
| 12.2(18)SXF16                 | MP001                             |
+-------------------------------------------------------------------+

Cisco IOS Software Modularity Maintenance Pack for 12.2SXH
+---------------------------------------------------------

+-------------------------------------------------------------------+
|  Cisco IOS Software Release   |   Solution Maintenance Pack(MP)   |
|-------------------------------+-----------------------------------|
| 12.2(33)SXH3                  | MP003                             |
|-------------------------------+-----------------------------------|
| 12.2(33)SXH4                  | MP002                             |
|-------------------------------+-----------------------------------|
| 12.2(33)SXH5                  | MP001                             |
+-------------------------------------------------------------------+

Workarounds
===========

There are no workarounds for this vulnerability.

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at:

http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html

or as otherwise set forth at Cisco.com Downloads at:

http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to:

http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html

for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was discovered by Cisco during internal testing.
The Cisco PSIRT is not aware of malicious exploitation of this
vulnerability, although we are aware of some customers who have seen
this vulnerability triggered within their infrastructures.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-auth-proxy.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+----------------------------------------+
| Revision |                   | Initial |
| 1.0      | 2009-September-23 | public  |
|          |                   | release |
+----------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and
registering to receive security information from Cisco, is available
on Cisco's worldwide website at:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

This includes instructions for press inquiries regarding Cisco security
notices. All Cisco security advisories are available at:

http://www.cisco.com/go/psirt
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukF886n/Gc8U/uARAterAJ9rtqHnNgutl0dgsYwBYzS0bOsvggCgmfPe
enMQhMdVPH6I4eGhvb6jKXg=
=9HOM
-----END PGP SIGNATURE-----

From psirt at cisco.com  Wed Sep 23 12:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Internet Key
	Exchange Resource Exhaustion Vulnerability
Message-ID: <200909231215.ipsec@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Internet Key Exchange
Resource Exhaustion Vulnerability

Advisory ID: cisco-sa-20090923-ipsec

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

Cisco IOS? devices that are configured for Internet Key Exchange
(IKE) protocol and certificate based authentication are vulnerable to
a resource exhaustion attack. Successful exploitation of this
vulnerability may result in the allocation of all available Phase 1
security associations (SA) and prevent the establishment of new IPsec
sessions.

Cisco has released free software updates that address this
vulnerability.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-ipsec.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

Cisco IOS devices that are configured for IKE and certificate based
authentication are affected.

Vulnerable Products
+------------------

IKE is enabled by default if IPsec is used. Cisco IOS devices that
are configured for IKE will listen on UDP port 500, UDP port 4500 if
the device is configured for NAT Traversal (NAT-T), or UDP ports 848
or 4848 if the device is configured for Group Domain of
Interpretation (GDOI). The following outputs show a router that is
listening on UDP port 500:

    Router#show ip sockets 
    Proto    Remote      Port      Local       Port  In Out Stat TTY OutputIF
    ....
     17   --listen--          192.168.66.129    500   0   0   11   0 
    ....

Or

    Router-#show udp
    Proto        Remote      Port      Local       Port  In Out  Stat TTY OutputIF
     17       --listen--          192.0.2.1         500   0   0  1011   0 
     17(v6)   --listen--          --any--           500   0   0 20011   0 
    Router#

IKE configurations that are performing certificate based
authentication will display "Rivest-Shamir-Adleman Signature" as the
authentication method in the output of the "show crypto isakmp policy"
command. This output is shown in the following example:

    Router#show crypto isakmp policy                               
    
    Global IKE policy
    Default protection suite
            encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
            hash algorithm:         Secure Hash Standard
            authentication method:  Rivest-Shamir-Adleman Signature
            Diffie-Hellman group:   #1 (768 bit)
            lifetime:               86400 seconds, no volume limit

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the 
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco 6500 Series device that is
running Cisco IOS Software release 12.2(18)SXF7 with an installed
image name of s72033_rp-IPSERVICESK9_WAN-M:

    Router#show version 
    Cisco Internetwork Operating System Software 
    IOS (tm) s72033_rp Software (s72033_rp-IPSERVICESK9_WAN-M), Version 12.2(18)SXF7, RELEASE SOFTWARE (fc1)
    Technical Support: http://www.cisco.com/techsupport
    Copyright ?) 1986-2006 by cisco Systems, Inc.
    Compiled Thu 23-Nov-06 06:42 by kellythw
    <output truncated>

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link:

http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+--------------------------------

Cisco IOS XR Software is not affected by this vulnerability.

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

IPsec is an IP security feature that provides robust authentication
and encryption of IP packets. IKE is a key management protocol
standard that is used in conjunction with the IPsec standard.

IKE is a hybrid protocol that implements the Oakley and SKEME key
exchanges inside the Internet Security Association and Key Management
Protocol (ISAKMP) framework. (ISAKMP, Oakley, and SKEME are security
protocols that are implemented by IKE.). More information on IKE is
available at the following link:

http://www.cisco.com/en/US/docs/ios/12_1/security/configuration/guide/scdike.html

A vulnerability exists in the IKE implementation of Cisco IOS
Software, if the certificate based authentication method is used.
Successful exploitation of this vulnerability may result in the
allocation of all available Phase 1 SAs, which may prevent new IPSec
sessions from being established.

Administrators can view Phase 1 SAs that are allocated as a result of
exploitation by issuing the "show crypto isakmp sa" command. The
following example displays sample output for this command:

    Router#show crypto isakmp sa
    IPv4 Crypto ISAKMP SA
    dst             src             state          conn-id slot status
    10.48.66.77     10.48.66.6      MM_KEY_EXCH       1004 ACTIVE
    10.48.66.77     10.48.66.6      MM_KEY_EXCH       1003 ACTIVE
    10.48.66.77     10.48.66.6      MM_KEY_EXCH       1002 ACTIVE
    ....

Any allocated SA can be de-allocated up manually by using the "clear
crypto isakmp <conn-ID>" command.

This vulnerability is addressed by the Cisco Bug IDs CSCsy07555 and
CSCee72997 and has been assigned Common Vulnerabilities and Exposures
(CVE) ID CVE-2009-2868.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerabilities in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss

CSCsy07555 - P1 SA stuck in KEY_EXCH forever

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

CSCee72997 - P1 SA stuck in KEY_EXCH forever

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of this vulnerability may result in the
allocation of all available Phase 1 SAs, which may prevent new IPsec
sessions from being established.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.0-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases                         |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.1-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases                         |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.2-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
| 12.2       | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2B      | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2BC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2BW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2BX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2BY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2BZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2CX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2CY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2CZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2DA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2DD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2DX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2EW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2EWA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Releases prior to 12.2(44)EX are      | 12.2(50)SE3  |
|            | vulnerable, release 12.2(44)EX and    |              |
| 12.2EX     | later are not vulnerable; migrate to  | 12.2(52)SE;  |
|            | any release in 12.2SEG                | Available on |
|            |                                       | 13-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.2EY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2EZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2FX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2FY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2FZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IRA    | Vulnerable; first fixed in 12.2SRD    | 12.2(33)SRD3 |
|------------+---------------------------------------+--------------|
| 12.2IRB    | Vulnerable; first fixed in 12.2SRD    | 12.2(33)SRD3 |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2IRC    | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
| 12.2IXA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXF    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXG    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXH    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2MB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2MC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2S      | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.2(31)SB16 |
| 12.2SB     | 12.2(33)SB6                           |              |
|            |                                       | 12.2(33)SB7  |
|------------+---------------------------------------+--------------|
| 12.2SBC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SCA    | Vulnerable; first fixed in 12.2SCB    | 12.2(33)SCB4 |
|------------+---------------------------------------+--------------|
| 12.2SCB    | 12.2(33)SCB4                          | 12.2(33)SCB4 |
|------------+---------------------------------------+--------------|
|            |                                       | 12.2(50)SE3  |
|            | 12.2(50)SE3                           |              |
| 12.2SE     |                                       | 12.2(52)SE;  |
|            | 12.2(52)SE; Available on 13-OCT-2009  | Available on |
|            |                                       | 13-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.2SEA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SED    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEF    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEG    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SGA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SO     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SRA    | Vulnerable; first fixed in 12.2SRD    | 12.2(33)SRD3 |
|------------+---------------------------------------+--------------|
| 12.2SRB    | Vulnerable; first fixed in 12.2SRD    | 12.2(33)SRD3 |
|------------+---------------------------------------+--------------|
| 12.2SRC    | 12.2(33)SRC5; Available on            | 12.2(33)SRD3 |
|            | 29-OCT-2009                           |              |
|------------+---------------------------------------+--------------|
|            | 12.2(33)SRD3                          |              |
| 12.2SRD    |                                       | 12.2(33)SRD3 |
|            | 12.2(33)SRD2a                         |              |
|------------+---------------------------------------+--------------|
| 12.2STE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SV     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SVA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SVC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SVD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SVE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXF    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | 12.2(33)SXH6; Available on            | 12.2(33)     |
|            | 30-OCT-2009                           | SXH6;        |
| 12.2SXH    |                                       | Available on |
|            | Please see IOS Software Modularity    | 30-OCT-2009  |
|            | Patch                                 |              |
|------------+---------------------------------------+--------------|
| 12.2SXI    | 12.2(33)SXI2a                         | 12.2(33)     |
|            |                                       | SXI2a        |
|------------+---------------------------------------+--------------|
| 12.2SY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2T      | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2TPC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XH     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XI     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XNA    | Please see Cisco IOS-XE Software      |              |
|            | Availability                          |              |
|------------+---------------------------------------+--------------|
| 12.2XNB    | Please see Cisco IOS-XE Software      |              |
|            | Availability                          |              |
|------------+---------------------------------------+--------------|
| 12.2XNC    | Please see Cisco IOS-XE Software      |              |
|            | Availability                          |              |
|------------+---------------------------------------+--------------|
| 12.2XND    | Please see Cisco IOS-XE Software      |              |
|            | Availability                          |              |
|------------+---------------------------------------+--------------|
| 12.2XO     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XS     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XT     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XV     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YH     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YN     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YO     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YP     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YS     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YT     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YV     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZH     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZP     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZYA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|  Affected  |                                       | Recommended  |
| 12.3-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
| 12.3       | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3B      | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3BC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3BW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3EU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; first fixed in 12.4       | 12.4(25b)    |
| 12.3T      |                                       |              |
|            | Releases up to and including 12.3(8)  | 12.4(23b)    |
|            | T11 are not vulnerable.               |              |
|------------+---------------------------------------+--------------|
| 12.3TPC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3VA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XI     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
|            |                                       | 12.4(22)T3   |
| 12.3XL     | Vulnerable; first fixed in 12.4T      |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.3XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XR     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XS     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.3XU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XX     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.3XY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3YA     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YD     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            | Vulnerable; migrate to any release in | 12.4(15)XR7  |
| 12.3YF     | 12.4XN                                |              |
|            |                                       | 12.4(22)XR   |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YG     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YH     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YI     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.3YJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YK     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.3YM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YQ     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YS     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YT     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YU     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            | Vulnerable; migrate to any release in | 12.4(15)XR7  |
| 12.3YX     | 12.4XN                                |              |
|            |                                       | 12.4(22)XR   |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.3YZ     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
| 12.3ZA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|  Affected  |                                       | Recommended  |
| 12.4-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
|            | Releases prior to 12.4(7) are         | 12.4(25b)    |
| 12.4       | vulnerable; Releases 12.4(7a) and     |              |
|            | later are not vulnerable.             | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.4GC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4SW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            | 12.4(4)T8                             | 12.4(20)T4   |
|            |                                       |              |
| 12.4T      | 12.4(9)T                              | 12.4(22)T3   |
|            |                                       |              |
|            | 12.4(6)T1                             | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XA     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XB     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XC     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XD     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4XE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XN     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XP     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XT     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XV     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4YA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4YB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4YD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4YE     | Not Vulnerable                        |              |
+-------------------------------------------------------------------+

Cisco IOS XE Software
+--------------------

+-------------------------------------------------------------------+
|     Cisco IOS XE Software Release     |    First Fixed Release    |
|---------------------------------------+---------------------------|
| 2.1.x                                 | 2.3.0t                    |
|---------------------------------------+---------------------------|
| 2.2.x                                 | 2.3.0t                    |
|---------------------------------------+---------------------------|
| 2.3.x                                 | Not Vulnerable            |
|---------------------------------------+---------------------------|
| 2.4.x                                 | Not Vulnerable            |
+-------------------------------------------------------------------+

Cisco IOS Software Modularity - Maintenance Packs
+------------------------------------------------

Customers who are using Cisco IOS Software Modularity can apply the
respective maintenance packs. More information on Cisco IOS Software
Modularity can be found at the following link:

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_bulletin0900aecd80313e15.html

The Maintenance Packs listed below can be downloaded at:

http://www.cisco.com/go/pn

Cisco IOS Software Modularity Maintenance Pack for 12.2SXH
+---------------------------------------------------------

+-------------------------------------------------------------------+
|  Cisco IOS Software Release   |   Solution Maintenance Pack(MP)   |
|-------------------------------+-----------------------------------|
| 12.2(33)SXH3                  | MP003                             |
|-------------------------------+-----------------------------------|
| 12.2(33)SXH4                  | MP002                             |
|-------------------------------+-----------------------------------|
| 12.2(33)SXH5                  | MP001                             |
+-------------------------------------------------------------------+

Workarounds
===========

There are no workarounds for this vulnerability.

Additional mitigations that can be deployed on Cisco devices in the
network are available in the Cisco Applied Mitigation Bulletin
companion document for this advisory, which is available at the
following link:

http://www.cisco.com/warp/public/707/cisco-amb-20090923-ipsec.shtml

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at:

http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html

or as otherwise set forth at Cisco.com Downloads at:

http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to:

http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html

for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was reported to Cisco by a customer.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-ipsec.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+----------------------------------------+
| Revision |                   | Initial |
| 1.0      | 2009-September-23 | public  |
|          |                   | release |
+----------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and
registering to receive security information from Cisco, is available
on Cisco's worldwide website at:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

This includes instructions for press inquiries regarding Cisco security
notices. All Cisco security advisories are available at:

http://www.cisco.com/go/psirt
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukGS86n/Gc8U/uARAra6AJ0TewwCLaVWd9M++iaztx1+pEWi6QCfdP8l
OST6ldrzEu8BBhfiZe0wApg=
=9J0c
-----END PGP SIGNATURE-----

From psirt at cisco.com  Wed Sep 23 12:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software H.323 Denial of
	Service Vulnerability
Message-ID: <200909231215.h323@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software H.323 Denial of Service
Vulnerability

Advisory ID: cisco-sa-20090923-h323

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

The H.323 implementation in Cisco IOS? Software contains a
vulnerability that can be exploited remotely to cause a device that
is running Cisco IOS Software to reload.

Cisco has released free software updates that address this
vulnerability. There are no workarounds to mitigate the vulnerability
apart from disabling H.323 if the device that is running Cisco IOS
Software does not need to run H.323 for VoIP services.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-h323.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

Vulnerable Products
+------------------

Cisco devices that are running affected Cisco IOS Software versions
that are configured to process H.323 messages are affected by this
vulnerability. H.323 is not enabled by default.

To determine the Cisco IOS Software device is running H.323 services
use the "show process cpu | include 323" command, as shown in the
following example:

    Router#show process cpu | include 323
     249       16000           3       5333  0.00%  0.00%  0.00%   0 CCH323_CT
     250           0           1          0  0.00%  0.00%  0.00%   0 CCH323_DNS
    Router# 

Note: Only H.323 listening port TCP 1720 is affected.

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the 
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
    Cisco Internetwork Operating System Software
    IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by cisco Systems, Inc.
    Compiled Mon 17-Mar-08 14:39 by dchih
    
    
    !--- output truncated
    

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.4(20)T with an installed image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team
    
    
    !--- output truncated
    

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link:

http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+--------------------------------

Cisco IOS XE and Cisco IOS XR Software are not affected by this
vulnerability. No other Cisco products are currently known to be
affected by this vulnerability.

Details
=======

H.323 is the ITU standard for real-time multimedia communications and
conferencing over packet-based (IP) networks. A subset of the H.323
standard is H.225.0, a standard used for call signalling protocols
and media stream packetization over IP networks.

The H.323 implementation in Cisco IOS Software contains a
vulnerability. An attacker can exploit this vulnerability remotely by
sending an H.323 crafted packet to the affected device that is
running Cisco IOS Software. A TCP three-way handshake is needed to
exploit this vulnerability.

This vulnerability is documented in Cisco bug ID CSCsz38104 and has
been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-2866.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss

CSCsz38104 - Crafted H323 packets may cause device to reload

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability described in this
document may cause the affected device to reload. The issue could be
exploited repeatedly to cause an extended DoS condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.0-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.1-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.2-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
| 12.2       | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; first fixed in 12.4       | 12.4(25b)    |
| 12.2B      |                                       |              |
|            | Releases up to and including 12.2(4)  | 12.4(23b)    |
|            | B8 are not vulnerable.                |              |
|------------+---------------------------------------+--------------|
| 12.2BC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2BW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; first fixed in 12.4       | 12.4(25b)    |
| 12.2BX     |                                       |              |
|            | Releases up to and including 12.2(15) | 12.4(23b)    |
|            | BX are not vulnerable.                |              |
|------------+---------------------------------------+--------------|
| 12.2BY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2BZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2CX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2CY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2CZ     | Vulnerable; migrate to 12.2SB         | 12.2(33)SB7  |
|------------+---------------------------------------+--------------|
| 12.2DA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2DD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2DX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2EW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2EWA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2EX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2EY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2EZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2FX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2FY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2FZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IRA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IRB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IRC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXF    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXG    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXH    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2MB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Releases up to and including 12.2(15) |              |
|            | MC1 are not vulnerable.               | 12.4(25b)    |
| 12.2MC     |                                       |              |
|            | Releases 12.2(15)MC2b and later are   | 12.4(23b)    |
|            | not vulnerable; first fixed in 12.4   |              |
|------------+---------------------------------------+--------------|
| 12.2S      | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SBC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SCA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SCB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SED    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEF    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEG    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SGA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SO     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SRA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SRB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SRC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SRD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2STE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SV     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SVA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SVC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SVD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SVE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXF    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXH    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXI    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; first fixed in 12.4       | 12.4(25b)    |
| 12.2T      |                                       |              |
|            | Releases up to and including 12.2(8)  | 12.4(23b)    |
|            | T10 are not vulnerable.               |              |
|------------+---------------------------------------+--------------|
| 12.2TPC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XH     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XI     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XNA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XNB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XNC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XND    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XO     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XS     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XT     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XV     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2YH     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2YJ     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
| 12.2YK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2YL     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.2YM     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2YN     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
| 12.2YO     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YP     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YS     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2YT     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2YU     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            | Releases prior to 12.2(11)YV1 are     |              |
| 12.2YV     | vulnerable, release 12.2(11)YV1 and   |              |
|            | later are not vulnerable              |              |
|------------+---------------------------------------+--------------|
| 12.2YW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2ZC     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2ZD     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.2ZE     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.2ZF     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.2ZG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.2ZH     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2ZJ     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2ZL     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2ZP     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
| 12.2ZU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZYA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|  Affected  |                                       | Recommended  |
| 12.3-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3       | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3B      | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.3BC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3BW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3EU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Releases up to and including 12.3(2)  |              |
|            | JK3 are not vulnerable.               | 12.4(25b)    |
| 12.3JK     |                                       |              |
|            | Releases 12.3(8)JK1 and later are not | 12.4(23b)    |
|            | vulnerable; first fixed in 12.4       |              |
|------------+---------------------------------------+--------------|
| 12.3JL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3T      | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.3TPC    | Releases up to and including 12.3(4)  |              |
|            | TPC11a are not vulnerable.            |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3VA     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            | Releases prior to 12.3(2)XA7 are      | 12.4(25b)    |
| 12.3XA     | vulnerable, release 12.3(2)XA7 and    |              |
|            | later are not vulnerable; first fixed | 12.4(23b)    |
|            | in 12.4                               |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.3XB     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XC     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XD     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XE     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.3XF     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XG     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            | Note: Releases prior to 12.3(7)XI11   | 12.2(33)SB7  |
| 12.3XI     | are vulnerable, release 12.3(7)XI11   |              |
|            | and later are not vulnerable;         | 12.2(31)SB16 |
|------------+---------------------------------------+--------------|
| 12.3XJ     | Vulnerable; migrate to any release in | 12.4(15)T10  |
|            | 12.4XN                                |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XK     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XL     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XQ     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XR     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.3XS     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            | Vulnerable; first fixed in 12.4T      | 12.4(20)T4   |
|            |                                       |              |
| 12.3XU     | Releases up to and including 12.3(8)  | 12.4(22)T3   |
|            | XU1 are not vulnerable.               |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            | Vulnerable; migrate to any release in | 12.4(15)XR7  |
| 12.3XW     | 12.4XR                                |              |
|            |                                       | 12.4(22)XR   |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XX     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XY     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XZ     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.3YA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; migrate to any release in | 12.4(15)XR7  |
| 12.3YF     | 12.4XR                                |              |
|            |                                       | 12.4(22)XR   |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YG     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.3YH     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YI     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            | Releases prior to 12.3(11)YK3 are     | 12.4(20)T4   |
|            | vulnerable, release 12.3(11)YK3 and   |              |
| 12.3YK     | later are not vulnerable; first fixed | 12.4(22)T3   |
|            | in 12.4T                              |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YM     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YQ     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            | Vulnerable; first fixed in 12.4T      | 12.4(20)T4   |
|            |                                       |              |
| 12.3YS     | Releases up to and including 12.3(11) | 12.4(22)T3   |
|            | YS1 are not vulnerable.               |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YT     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YU     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)XR7  |
| 12.3YX     | Vulnerable; migrate to 12.4XR         |              |
|            |                                       | 12.4(22)XR   |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.3YZ     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3ZA     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|  Affected  |                                       | Recommended  |
| 12.4-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
|            | 12.4(25b)                             | 12.4(25b)    |
| 12.4       |                                       |              |
|            | 12.4(23b)                             | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.4GC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Releases prior to 12.4(19)MR3 are     |              |
| 12.4MR     | vulnerable, release 12.4(19)MR3 and   |              |
|            | later are not vulnerable              |              |
|------------+---------------------------------------+--------------|
| 12.4SW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            | 12.4(15)T10                           |              |
|            |                                       | 12.4(20)T4   |
|            | 12.4(20)T4                            |              |
| 12.4T      |                                       | 12.4(22)T3   |
|            | 12.4(22)T2                            |              |
|            |                                       | 12.4(24)T2;  |
|            | 12.4(24)T1                            | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XA     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XB     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XC     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XD     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XE     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XJ     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.4XL     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            | Vulnerable; first fixed in 12.4T      | 12.4(20)T4   |
|            |                                       |              |
| 12.4XM     | Releases up to and including 12.4(15) | 12.4(22)T3   |
|            | XM are not vulnerable.                |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4XN     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.4XP     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
| 12.4XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XT     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.4XV     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XW     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XY     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XZ     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4YA     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4YB     | 12.4(22)YB4                           | 12.4(22)YB4  |
|------------+---------------------------------------+--------------|
| 12.4YD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4YE     | Not Vulnerable                        |              |
+-------------------------------------------------------------------+

Note: No Cisco IOS-XE Software or Cisco IOS Software Modularity
releases are affected by this vulnerability.

Workarounds
===========

There are no workarounds to mitigate the vulnerability apart from
disabling H.323 if the Cisco IOS device does not need to run H.323
for VoIP services. Affected devices that must run H.323 are
vulnerable, and there are not any specific configurations that can be
used to protect them. Applying access lists on interfaces that should
not accept H.323 traffic and putting firewalls in strategic locations
may greatly reduce exposure until an upgrade can be performed.

Cisco provides Solution Reference Network Design (SRND) guides to
help design and deploy networking solutions, which can be found at 
http://www.cisco.com/go/srnd Voice Security best practices are
covered in the Cisco Unified Communications SRND Based on Cisco
Unified Communications Manager 6.x at:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/6x/security.html

Below is an example of an access list to block H.323 management
traffic from anywhere but a permitted network. In this example, the
permitted network is 172.16.0.0/16.

    
    !--- Permit access from any IP address in the 172.16.0.0/16 
    !--- network to anywhere on port 1720.
    
    
    access-list 101 permit tcp 172.16.0.0 0.0.255.255 any eq 1720
    
    
    !--- Permit access from anywhere to a host in the 
    !--- 172.16.0.0/26 network on port 1720.
    
     
    access-list 101 permit tcp any 172.16.0.0 0.0.255.255 eq 1720
    
    
    !--- Deny all traffic from port 1720.
    
    
    access-list 101 deny tcp any eq 1720 any
    
    
    !--- Deny all traffic to port 1720.
    
    
    access-list 101 deny tcp any any eq 1720
    
    
    !--- Permit all other traffic.
    
    
    access-list 101 permit ip any any

Alternatively, you can use the "call service stop forced" command under
the "voice service voip" mode, as shown in the following example:

    voice service voip
     h323
      call service stop forced

Additional mitigations that can be deployed on Cisco devices within
the network are available in the companion document "Cisco Applied
Mitigation Bulletin: Identifying and Mitigating Exploitation of the
Denial of Service Vulnerabilities in Cisco Unified Communications
Manager and Cisco IOS Software", which is available at the following
location:

http://www.cisco.com/warp/public/707/cisco-amb-20090923-voice.shtml

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at:

http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html

or as otherwise set forth at Cisco.com Downloads at:

http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to:

http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html

for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was found during internal testing.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-h323.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+----------------------------------------+
| Revision |                   | Initial |
| 1.0      | 2009-September-23 | public  |
|          |                   | release |
+----------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and
registering to receive security information from Cisco, is available
on Cisco's worldwide website at:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

This includes instructions for press inquiries regarding Cisco security
notices. All Cisco security advisories are available at:

http://www.cisco.com/go/psirt
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukGL86n/Gc8U/uARAg57AJ9RtkzXFDXBhVYa/uszbYnplu2nhgCeJmtM
vims3xWW7vcpqLkfphuJWzs=
=eh5W
-----END PGP SIGNATURE-----

From psirt at cisco.com  Wed Sep 23 12:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Tunnels
	Vulnerability
Message-ID: <200909231215.tunnels@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Tunnels Vulnerability

Advisory ID: cisco-sa-20090923-tunnels

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

Cisco devices running affected versions of Cisco IOS Software are
vulnerable to a denial of service (DoS) attack if configured for IP
tunnels and Cisco Express Forwarding.

Cisco has released free software updates that address this
vulnerability.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-tunnels.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

Cisco devices are vulnerable when running an affected version of
Cisco IOS Software and configured for Generic Routing Encapsulation
(GRE), IPinIP, Generic Packet Tunneling in IPv6 or IPv6 over IP
tunnels with Cisco Express Forwarding enabled. The Cisco IOS Point to
Point Tunneling Protocol (PPTP) feature creates GRE tunnels that are
transparent to the user. Therefore systems configured for PPTP are
also vulnerable.

The Cisco multicast Virtual Private Network (MVPN) feature also
creates GRE tunnels that are transparent to the user, however MVPN
configurations are not vulnerable, unless there are other tunnels
that are configured explicitly.

Vulnerable Products
+------------------

A Cisco IOS device that is explicitly configured for a tunnel will
have a configuration similar to the following in the output of "show
running-config":

    interface tunnel0
     ip address [IP-address]
     tunnel source [Tunnel-Source]
     tunnel destination [Tunnel Destination]
    

An alternative method to identify devices that are configured for
tunnels is to use the "show interfaces" command. A sample output is
provided below:

    Router#show interfaces | include Tunnel
    Tunnel0 is up, line protocol is down
      Hardware is Tunnel
      [...]
      Tunnel protocol/transport GRE/IP
    
    !-- output truncated
    

A Cisco IOS device that is configured for Cisco Express Forwarding
will display the forwarding table in the output of "show ip cef"
output, as in the following example:

    Router#show ip cef
    Prefix              Next Hop             Interface
    0.0.0.0/0           10.48.64.1           Ethernet0/0
    0.0.0.0/32          receive
    ....

Cisco Express Forwarding is enabled by default in most Cisco IOS
Software versions.

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the 
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco 7200 series device running
Cisco IOS Software release 12.3(19) with an installed image name of
C7200-JS-M:

    7200#show version 
    Cisco Internetwork Operating System Software 
    IOS (tm) 7200 Software (C7200-JS-M), Version 12.3(19), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2006 by cisco Systems, Inc.
    Compiled Thu 11-May-06 22:37 by evmiller
    
    !-- output truncated
    

The following example identifies a Cisco 7300 series device running
Cisco IOS Software release 12.3(22) with an installed image name of
C7301-P-M:

    7301# show version 
    Cisco Internetwork Operating System Software 
    IOS (tm) 7301 Software (C7301-P-M), Version 12.3(22), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2007 by cisco Systems, Inc.
    Compiled Wed 24-Jan-07 20:26 by ccai
    
    !-- output truncated
    

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link:

http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+--------------------------------

Cisco IOS XR Software is not affected.

Cisco IOS XE Software is not affected.

IPsec and Dynamic Multipoint VPN (DMVPN) configurations that are
protected by IPsec are not affected.

MVPN configurations are not affected.

Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) tunnels
are not affected.

No other Cisco products are currently known to be affected by these
vulnerabilities.

Details
=======

A tunnel protocol encapsulates a wide variety of protocol packet
types inside IP tunnels, creating a virtual point-to-point link
between internetworking devices over an IP network.

Cisco Express Forwarding is a Layer 3 IP switching technology. It
improves network performance and scalability for networks with high
and dynamic traffic patterns.

Devices that are running Cisco IOS Software and configured for GRE,
IPinIP, Generic Packet Tunneling in IPv6 or IPv6 over IP tunnels
tunnels and Cisco Express Forwarding may reload upon switching a
specially crafted malformed packets. Please note that using PPTP
creates GRE tunnels that are transparent to the end user so devices
configured for PPTP are vulnerable if they are configured on an
affected software version. Using MVPN also creates GRE tunnels that
are transparent to the end user. However MVPN configurations are not
vulnerable.

These vulnerabilities are addressed by the Cisco Bug IDs CSCsh97579,
CSCsq31776 and CSCsx70889 and have been assigned
Common Vulnerabilities and Exposures (CVE) IDs CVE-2009-2872 and
CVE-2009-2873.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerabilities in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss

CSCsh97579 - switching bad packet tunnel to tunnel crashes router

CVSS Base Score - 7.1

Access Vector           - Network
Access Complexity       - Medium
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 5.9

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

CSCsq31776 - ip tunnels regression test can crash the router

CVSS Base Score - 7.1

Access Vector           - Network
Access Complexity       - Medium
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 5.9

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

CSCsx70889 - Systems configured for tunnels reload after receiving malformed packets

CVSS Base Score - 7.1

Access Vector           - Network
Access Complexity       - Medium
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 5.9

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability may result in the reload
of an affected system, causing a DoS condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
|  Affected  |                                      |  Recommended  |
| 12.0-Based |         First Fixed Release          |    Release    |
|  Releases  |                                      |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0       | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0DA     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.4      | 12.4(25b)     |
| 12.0DB     |                                      |               |
|            | Releases up to and including 12.0(1) | 12.4(23b)     |
|            | DB are not vulnerable.               |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0DC     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | 12.0(32)S14; Available on            | 12.0(33)S5    |
|            | 25-SEP-2009                          |               |
| 12.0S      |                                      | 12.0(32)S14;  |
|            | 12.0(33)S5                           | Available on  |
|            |                                      | 25-SEP-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.0(33)S5    |
|            |                                      |               |
| 12.0SC     | Vulnerable; first fixed in 12.0S     | 12.0(32)S14;  |
|            |                                      | Available on  |
|            |                                      | 25-SEP-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.0(33)S5    |
|            |                                      |               |
| 12.0SL     | Vulnerable; first fixed in 12.0S     | 12.0(32)S14;  |
|            |                                      | Available on  |
|            |                                      | 25-SEP-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0SP     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.0(33)S5    |
|            |                                      |               |
| 12.0ST     | Vulnerable; first fixed in 12.0S     | 12.0(32)S14;  |
|            |                                      | Available on  |
|            |                                      | 25-SEP-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.0(33)S5    |
|            |                                      |               |
| 12.0SX     | Vulnerable; first fixed in 12.0S     | 12.0(32)S14;  |
|            |                                      | Available on  |
|            |                                      | 25-SEP-2009   |
|------------+--------------------------------------+---------------|
|            | 12.0(32)SY9a                         | 12.0(32)SY9a  |
|            |                                      |               |
| 12.0SY     | 12.0(32)SY10; Available on           | 12.0(32)SY10; |
|            | 25-SEP-2009                          | Available on  |
|            |                                      | 25-SEP-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.0(33)S5    |
|            |                                      |               |
| 12.0SZ     | Vulnerable; first fixed in 12.0S     | 12.0(32)S14;  |
|            |                                      | Available on  |
|            |                                      | 25-SEP-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0T      | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.4      | 12.4(25b)     |
| 12.0W      |                                      |               |
|            | Releases up to and including 12.0    | 12.4(23b)     |
|            | (16)W5(21c) are not vulnerable.      |               |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.0(5)WC3b are    |               |
| 12.0WC     | vulnerable, release 12.0(5)WC3b and  |               |
|            | later are not vulnerable             |               |
|------------+--------------------------------------+---------------|
| 12.0WT     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0XA     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0XB     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0XC     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0XD     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0XE     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
| 12.0XF     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0XG     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0XH     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.0(4)XI2 are     | 12.4(25b)     |
| 12.0XI     | vulnerable, release 12.0(4)XI2 and   |               |
|            | later are not vulnerable; first      | 12.4(23b)     |
|            | fixed in 12.4                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0XJ     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0XK     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0XL     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0XM     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0XN     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0XQ     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.4      | 12.4(25b)     |
| 12.0XR     |                                      |               |
|            | Releases up to and including 12.0(6) | 12.4(23b)     |
|            | XR are not vulnerable.               |               |
|------------+--------------------------------------+---------------|
| 12.0XS     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0XT     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.0XV     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|  Affected  |                                      |  Recommended  |
| 12.1-Based |         First Fixed Release          |    Release    |
|  Releases  |                                      |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1       | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1AA     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(50)SE3   |
|            |                                      |               |
| 12.1AX     | Vulnerable; first fixed in 12.2SE    | 12.2(52)SE;   |
|            |                                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            | Releases up to and including 12.1    | 12.2(50)SE3   |
|            | (13)AY are not vulnerable.           |               |
| 12.1AY     |                                      | 12.2(52)SE;   |
|            | Releases 12.1(22)AY1 and later are   | Available on  |
|            | not vulnerable; first fixed in       | 13-OCT-2009   |
|            | 12.2SE                               |               |
|------------+--------------------------------------+---------------|
| 12.1AZ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1CX     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1DA     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1DB     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1DC     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(18)      |
| 12.1E      | Vulnerable; first fixed in 12.2SXF   | SXF17;        |
|            |                                      | Available on  |
|            |                                      | 30-SEP-2009   |
|------------+--------------------------------------+---------------|
|            | Releases up to and including 12.1(4) |               |
|            | EA1c are not vulnerable.             |               |
| 12.1EA     |                                      | 12.2(50)SE3   |
|            | Releases 12.1(22)EA11 and later are  |               |
|            | not vulnerable; first fixed in       |               |
|            | 12.2SE                               |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.1EB     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(33)SCB4  |
| 12.1EC     | Vulnerable; first fixed in 12.3BC    |               |
|            |                                      | 12.3(21a)BC9  |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.1EO     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(31)SGA11 |
| 12.1EU     | Vulnerable; first fixed in 12.2SG    |               |
|            |                                      | 12.2(50)SG4   |
|------------+--------------------------------------+---------------|
| 12.1EV     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1EW     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1EX     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
| 12.1EY     | Releases up to and including 12.1(1) |               |
|            | EY are not vulnerable.               |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1EZ     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1GA     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1GB     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1T      | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XA     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XB     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XC     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XD     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XE     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XF     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XG     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XH     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XI     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XJ     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XL     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XM     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XP     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XQ     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XR     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.4      | 12.4(25b)     |
| 12.1XS     |                                      |               |
|            | Releases up to and including 12.1(1) | 12.4(23b)     |
|            | XS are not vulnerable.               |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XT     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XU     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XV     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XW     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XX     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.4      | 12.4(25b)     |
| 12.1XY     |                                      |               |
|            | Releases up to and including 12.1(4) | 12.4(23b)     |
|            | XY are not vulnerable.               |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1XZ     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1YA     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1YB     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1YC     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1YD     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.1(5)YE6 are     | 12.4(25b)     |
| 12.1YE     | vulnerable, release 12.1(5)YE6 and   |               |
|            | later are not vulnerable; first      | 12.4(23b)     |
|            | fixed in 12.4                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1YF     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.1YH     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.1YI     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.1YJ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|  Affected  |                                      |  Recommended  |
| 12.2-Based |         First Fixed Release          |    Release    |
|  Releases  |                                      |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2       | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2B      | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2BC     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2BW     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2BX     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2BY     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2BZ     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2CX     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2CY     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(31)SB16  |
| 12.2CZ     | Vulnerable; first fixed in 12.2SB    |               |
|            |                                      | 12.2(33)SB7   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2DA     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2DD     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2DX     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(31)SGA11 |
| 12.2EW     | Vulnerable; first fixed in 12.2SG    |               |
|            |                                      | 12.2(50)SG4   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(31)SGA11 |
| 12.2EWA    | Vulnerable; first fixed in 12.2SG    |               |
|            |                                      | 12.2(50)SG4   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(50)SE3   |
|            |                                      |               |
| 12.2EX     | Vulnerable; first fixed in 12.2SE    | 12.2(52)SE;   |
|            |                                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.2(46)EY are     | 12.2(50)SE3   |
|            | vulnerable, release 12.2(46)EY and   |               |
| 12.2EY     | later are not vulnerable; first      | 12.2(52)SE;   |
|            | fixed in 12.2SE                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(50)SE3   |
|            |                                      |               |
| 12.2EZ     | Vulnerable; first fixed in 12.2SE    | 12.2(52)SE;   |
|            |                                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
| 12.2FX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2FY     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(50)SE3   |
|            |                                      |               |
| 12.2FZ     | Vulnerable; first fixed in 12.2SE    | 12.2(52)SE;   |
|            |                                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
| 12.2IRA    | Vulnerable; first fixed in 12.2SRD   | 12.2(33)SRD3  |
|------------+--------------------------------------+---------------|
| 12.2IRB    | Vulnerable; first fixed in 12.2SRD   | 12.2(33)SRD3  |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IRC    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IXA    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IXB    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IXC    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IXD    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IXE    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IXF    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IXG    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2IXH    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.2JA     | Releases up to and including 12.2    |               |
|            | (13)JA4 are not vulnerable.          |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2JK     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2MB     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2MC     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(31)SB16  |
| 12.2S      | Vulnerable; first fixed in 12.2SB    |               |
|            |                                      | 12.2(33)SB7   |
|------------+--------------------------------------+---------------|
|            | 12.2(31)SB16                         |               |
|            |                                      |               |
| 12.2SB     | 12.2(33)SB6                          | 12.2(33)SB7   |
|            |                                      |               |
|            | 12.2(28)SB14; Available on           |               |
|            | 20-OCT-2009                          |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(31)SB16  |
| 12.2SBC    | Vulnerable; first fixed in 12.2SB    |               |
|            |                                      | 12.2(33)SB7   |
|------------+--------------------------------------+---------------|
| 12.2SCA    | Vulnerable; first fixed in 12.2SCB   | 12.2(33)SCB4  |
|------------+--------------------------------------+---------------|
| 12.2SCB    | 12.2(33)SCB4                         | 12.2(33)SCB4  |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(50)SE3   |
|            | 12.2(50)SE2                          |               |
| 12.2SE     |                                      | 12.2(52)SE;   |
|            | 12.2(52)SE; Available on 13-OCT-2009 | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(50)SE3   |
|            |                                      |               |
| 12.2SEA    | Vulnerable; first fixed in 12.2SE    | 12.2(52)SE;   |
|            |                                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(50)SE3   |
|            |                                      |               |
| 12.2SEB    | Vulnerable; first fixed in 12.2SE    | 12.2(52)SE;   |
|            |                                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(50)SE3   |
|            |                                      |               |
| 12.2SEC    | Vulnerable; first fixed in 12.2SE    | 12.2(52)SE;   |
|            |                                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(50)SE3   |
|            |                                      |               |
| 12.2SED    | Vulnerable; first fixed in 12.2SE    | 12.2(52)SE;   |
|            |                                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(50)SE3   |
|            |                                      |               |
| 12.2SEE    | Vulnerable; first fixed in 12.2SE    | 12.2(52)SE;   |
|            |                                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.2(25)SEF2 are   | 12.2(50)SE3   |
|            | vulnerable, release 12.2(25)SEF2 and |               |
| 12.2SEF    | later are not vulnerable; first      | 12.2(52)SE;   |
|            | fixed in 12.2SE                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.2(25)SEG4 are   | 12.2(50)SE3   |
|            | vulnerable, release 12.2(25)SEG4 and |               |
| 12.2SEG    | later are not vulnerable; first      | 12.2(52)SE;   |
|            | fixed in 12.2SE                      | Available on  |
|            |                                      | 13-OCT-2009   |
|------------+--------------------------------------+---------------|
|            | 12.2(50)SG4                          |               |
| 12.2SG     |                                      | 12.2(50)SG4   |
|            | 12.2(53)SG                           |               |
|------------+--------------------------------------+---------------|
| 12.2SGA    | 12.2(31)SGA11                        | 12.2(31)SGA11 |
|------------+--------------------------------------+---------------|
| 12.2SL     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2SM     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2SO     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2SQ     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.2SRA    | Vulnerable; first fixed in 12.2SRD   | 12.2(33)SRD3  |
|------------+--------------------------------------+---------------|
| 12.2SRB    | Vulnerable; first fixed in 12.2SRD   | 12.2(33)SRD3  |
|------------+--------------------------------------+---------------|
| 12.2SRC    | 12.2(33)SRC5; Available on           | 12.2(33)SRD3  |
|            | 29-OCT-2009                          |               |
|------------+--------------------------------------+---------------|
| 12.2SRD    | 12.2(33)SRD2                         | 12.2(33)SRD3  |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2STE    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2SU     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2SV     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2SVA    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2SVC    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2SVD    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2SVE    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.2SW     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(18)      |
| 12.2SX     | Vulnerable; first fixed in 12.2SXF   | SXF17;        |
|            |                                      | Available on  |
|            |                                      | 30-SEP-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(18)      |
| 12.2SXA    | Vulnerable; first fixed in 12.2SXF   | SXF17;        |
|            |                                      | Available on  |
|            |                                      | 30-SEP-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(18)      |
| 12.2SXB    | Vulnerable; first fixed in 12.2SXF   | SXF17;        |
|            |                                      | Available on  |
|            |                                      | 30-SEP-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(18)      |
| 12.2SXD    | Vulnerable; first fixed in 12.2SXF   | SXF17;        |
|            |                                      | Available on  |
|            |                                      | 30-SEP-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(18)      |
| 12.2SXE    | Vulnerable; first fixed in 12.2SXF   | SXF17;        |
|            |                                      | Available on  |
|            |                                      | 30-SEP-2009   |
|------------+--------------------------------------+---------------|
|            | 12.2(18)SXF17; Available on          | 12.2(18)      |
|            | 30-SEP-2009                          | SXF17;        |
| 12.2SXF    |                                      | Available on  |
|            | Please see IOS Software Modularity   | 30-SEP-2009   |
|            | Patch                                |               |
|------------+--------------------------------------+---------------|
|            | 12.2(33)SXH6; Available on           |               |
|            | 30-OCT-2009                          | 12.2(33)SXH6; |
| 12.2SXH    |                                      | Available on  |
|            | Please see IOS Software Modularity   | 30-OCT-2009   |
|            | Patch                                |               |
|------------+--------------------------------------+---------------|
| 12.2SXI    | 12.2(33)SXI2                         | 12.2(33)SXI2a |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(31)SB16  |
| 12.2SY     | Vulnerable; first fixed in 12.2SB    |               |
|            |                                      | 12.2(33)SB7   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(31)SB16  |
| 12.2SZ     | Vulnerable; first fixed in 12.2SB    |               |
|            |                                      | 12.2(33)SB7   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2T      | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2TPC    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.4      | 12.4(25b)     |
| 12.2XA     |                                      |               |
|            | Releases up to and including 12.2(1) | 12.4(23b)     |
|            | XA are not vulnerable.               |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XB     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XC     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XD     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XE     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XF     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XG     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XH     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XI     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XJ     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XK     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XL     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XM     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
| 12.2XNA    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2XNB    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2XNC    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.2XND    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(31)SGA11 |
| 12.2XO     | Vulnerable; first fixed in 12.2SG    |               |
|            |                                      | 12.2(50)SG4   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XQ     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XR     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XS     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XT     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XU     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XV     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2XW     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2YA     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YB     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YC     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YD     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YE     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YF     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YG     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YH     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YJ     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YK     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YL     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2YM     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YN     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YO     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; first fixed in 12.4      | 12.4(25b)     |
| 12.2YP     |                                      |               |
|            | Releases up to and including 12.2(8) | 12.4(23b)     |
|            | YP are not vulnerable.               |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YQ     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YR     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.2YS     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YT     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YU     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YV     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YW     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YX     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YY     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2YZ     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(18)      |
| 12.2ZA     | Vulnerable; first fixed in 12.2SXF   | SXF17;        |
|            |                                      | Available on  |
|            |                                      | 30-SEP-2009   |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2ZB     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2ZC     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2ZD     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2ZE     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2ZF     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2ZG     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.2ZH     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2ZJ     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2ZL     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2ZP     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(33)SXH6; |
| 12.2ZU     | Vulnerable; first fixed in 12.2SXH   | Available on  |
|            |                                      | 30-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(31)SB16  |
| 12.2ZX     | Vulnerable; first fixed in 12.2SB    |               |
|            |                                      | 12.2(33)SB7   |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.2ZY     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.2ZYA    | 12.2(18)ZYA2                         |               |
|------------+--------------------------------------+---------------|
|  Affected  |                                      |  Recommended  |
| 12.3-Based |         First Fixed Release          |    Release    |
|  Releases  |                                      |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3       | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3B      | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
| 12.3BC     | 12.3(21a)BC9                         | 12.3(21a)BC9  |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3BW     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
| 12.3EU     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.3JA     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.3JEA    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.3JEB    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.3JEC    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3JK     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.3JL     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.3JX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3T      | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.3TPC    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3VA     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3XA     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.3XB     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3XC     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3XD     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3XE     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.3XF     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3XG     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.2(31)SB16  |
| 12.3XI     | Vulnerable; first fixed in 12.2SB    |               |
|            |                                      | 12.2(33)SB7   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)XR7   |
| 12.3XJ     | Vulnerable; first fixed in 12.4XR    |               |
|            |                                      | 12.4(22)XR    |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3XK     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
|            |                                      | 12.4(22)T3    |
| 12.3XL     | Vulnerable; first fixed in 12.4T     |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3XQ     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3XR     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3XS     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3XU     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)XR7   |
| 12.3XW     | Vulnerable; first fixed in 12.4XR    |               |
|            |                                      | 12.4(22)XR    |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3XX     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3XY     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3XZ     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(25b)     |
| 12.3YA     | Vulnerable; first fixed in 12.4      |               |
|            |                                      | 12.4(23b)     |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YD     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)XR7   |
| 12.3YF     | Vulnerable; first fixed in 12.4XR    |               |
|            |                                      | 12.4(22)XR    |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YG     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YH     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YI     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YJ     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YK     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YM     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YQ     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YS     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YT     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3YU     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)XR7   |
| 12.3YX     | Vulnerable; first fixed in 12.4XR    |               |
|            |                                      | 12.4(22)XR    |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.3YZ     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.3ZA     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|  Affected  |                                      |  Recommended  |
| 12.4-Based |         First Fixed Release          |    Release    |
|  Releases  |                                      |               |
|------------+--------------------------------------+---------------|
|            | 12.4(23b)                            | 12.4(25b)     |
| 12.4       |                                      |               |
|            | 12.4(25b)                            | 12.4(23b)     |
|------------+--------------------------------------+---------------|
| 12.4GC     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JA     | 12.4(13d)JA                          |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.4JDA    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.4JDC    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.4JDD    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.4JK     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.4JL     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.4JMA    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.4JMB    | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
| 12.4JX     | Vulnerable; first fixed in 12.4JA    |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(11)MD9   |
|            |                                      |               |
| 12.4MD     | 12.4(11)MD9                          | 12.4(15)MD3   |
|            |                                      |               |
|            |                                      | 12.4(22)MD1   |
|------------+--------------------------------------+---------------|
| 12.4MDA    | 12.4(22)MDA1                         | 12.4(22)MDA1  |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.4(19)MR3 are    |               |
| 12.4MR     | vulnerable, release 12.4(19)MR3 and  | 12.4(19)MR3   |
|            | later are not vulnerable             |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4SW     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            | 12.4(15)T10                          |               |
|            |                                      | 12.4(20)T4    |
|            | 12.4(20)T4                           |               |
| 12.4T      |                                      | 12.4(22)T3    |
|            | 12.4(22)T2                           |               |
|            |                                      | 12.4(24)T2;   |
|            | 12.4(24)T2;Available on 23-OCT-2009  | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XA     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XB     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XC     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XD     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XE     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XF     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XG     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XJ     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XK     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.4XL     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XM     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.4XN     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.4XP     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XQ     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            | 12.4(22)XR                           | 12.4(15)XR7   |
| 12.4XR     |                                      |               |
|            | 12.4(15)XR6                          | 12.4(22)XR    |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XT     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            | Vulnerable; Contact your support     |               |
| 12.4XV     | organization per the instructions in |               |
|            | Obtaining Fixed Software section of  |               |
|            | this advisory                        |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XW     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XY     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4XZ     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(15)T10   |
|            |                                      |               |
|            |                                      | 12.4(20)T4    |
|            |                                      |               |
| 12.4YA     | Vulnerable; first fixed in 12.4T     | 12.4(22)T3    |
|            |                                      |               |
|            |                                      | 12.4(24)T2;   |
|            |                                      | Available on  |
|            |                                      | 23-OCT-2009   |
|------------+--------------------------------------+---------------|
| 12.4YB     | 12.4(22)YB4                          | 12.4(22)YB4   |
|------------+--------------------------------------+---------------|
| 12.4YD     | 12.4(22)YD1                          | 12.4(22)YD1   |
|------------+--------------------------------------+---------------|
| 12.4YE     | 12.4(22)YE1                          | 12.4(22)YE1   |
+-------------------------------------------------------------------+

Cisco IOS Software Modularity - Maintenance Packs
+------------------------------------------------

Customers who are using Cisco IOS Software Modularity can apply the
respective maintenance packs. More information on Cisco IOS Software
Modularity can be found at the following link:

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_bulletin0900aecd80313e15.html

The Maintenance Packs listed below can be downloaded at:

http://www.cisco.com/go/pn

Cisco IOS Software Modularity Maintenance Pack for 12.2SXF
+---------------------------------------------------------

+-------------------------------------------------------------------+
|  Cisco IOS Software Release   |   Solution Maintenance Pack(MP)   |
|-------------------------------+-----------------------------------|
| 12.2(18)SXF11                 | MP002                             |
|-------------------------------+-----------------------------------|
| 12.2(18)SXF13                 | MP001                             |
|-------------------------------+-----------------------------------|
| 12.2(18)SXF14                 | MP001                             |
|-------------------------------+-----------------------------------|
| 12.2(18)SXF15                 | MP001                             |
|-------------------------------+-----------------------------------|
| 12.2(18)SXF16                 | MP001                             |
+-------------------------------------------------------------------+

Cisco IOS Software Modularity Maintenance Pack for 12.2SXH

+-------------------------------------------------------------------+
|  Cisco IOS Software Release   |   Solution Maintenance Pack(MP)   |
|-------------------------------+-----------------------------------|
| 12.2(33)SXH3                  | MP003                             |
|-------------------------------+-----------------------------------|
| 12.2(33)SXH4                  | MP002                             |
|-------------------------------+-----------------------------------|
| 12.2(33)SXH5                  | MP001                             |
+-------------------------------------------------------------------+

Workarounds
===========

Disabling Cisco Express Forwarding will mitigate this vulnerability.
It can be disabled in two ways:

Disabling Cisco Express Forwarding Globally
+------------------------------------------

Cisco Express Forwarding can be globally disabled by using the "no ip
cef" global configuration command.

Disabling Cisco Express Forwarding on Tunnel Interfaces
+------------------------------------------------------

Cisco Express Forwarding can also be disabled on individual tunnel
interfaces. To be effective, it must be disabled on all tunnel
interfaces configured on an affected device. Cisco Express Forwarding
can be disabled on individual interfaces as shown in the following
example:

    interface Tunnel [interface-ID]
      no ip route-cache cef

Note: Disabling Cisco Express Forwarding may have significant
performance impact and is not recommended.

Additional mitigations that can be deployed on Cisco devices in the
network are available in the Cisco Applied Mitigation Bulletin
companion document for this advisory, which is available at the
following link:

http://www.cisco.com/warp/public/707/cisco-amb-20090923-tunnels.shtml

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at:

http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html

or as otherwise set forth at Cisco.com Downloads at:

http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to:

http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html

for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was found internally.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-tunnels.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+---------------------------------------+
| Revision |              | Initial     |
| 1.0      | 2009-Sept-23 | public      |
|          |              | release     |
+---------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and
registering to receive security information from Cisco, is available
on Cisco's worldwide website at:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

This includes instructions for press inquiries regarding Cisco security
notices. All Cisco security advisories are available at:

http://www.cisco.com/go/psirt
-----BEGIN PGP SIGNATURE-----

iD4DBQFKukGg86n/Gc8U/uARAjwOAJ0QiF6I23ZEDO/8uTK+i/pHtT7e+ACTBUn9
CciG6YUGAERIKR0YMq0gcQ==
=nkdE
-----END PGP SIGNATURE-----

From jsimola at gmail.com  Wed Sep 23 13:13:26 2009
From: jsimola at gmail.com (Jon Simola)
Date: Wed, 23 Sep 2009 10:13:26 -0700
Subject: [c-nsp] ospf hellos
In-Reply-To: <B3BB2565B39146A19ED745475660C165@EU.corp.clearwire.com>
References: <B3BB2565B39146A19ED745475660C165@EU.corp.clearwire.com>
Message-ID: <8eea04080909231013v4309f602m40a58107fa0c5aa0@mail.gmail.com>

On Wed, Sep 23, 2009 at 7:35 AM, Rens <rens at autempspourmoi.be> wrote:

> Is there a way to prioritize ospf hello packets with 802.1p?

They are by default. See
http://www.cisco.com/en/US/tech/tk543/tk544/technologies_tech_note09186a0080094612.shtml

"Cisco IOS assigns an IP precedence of 6 to routing protocol packets
on the control plane. As noted by RFC 791, "The Internetwork Control
designation is intended for use by gateway control originators only."
Specifically, Cisco IOS marks these IP-based control packets: Open
Shortest Path First (OSPF), Routing Information Protocol (RIP),
Enhanced Interior Gateway Routing Protocol (EIGRP) hellos, and
keepalives. Telnet packets to and from the router also receive an IP
precedence value of 6. The assigned value remains with the packets
when the output interface transmits them into the network."

-- 
Jon

From cchurc05 at harris.com  Wed Sep 23 15:01:39 2009
From: cchurc05 at harris.com (Church, Charles)
Date: Wed, 23 Sep 2009 15:01:39 -0400
Subject: [c-nsp] ospf hellos
In-Reply-To: <8eea04080909231013v4309f602m40a58107fa0c5aa0@mail.gmail.com>
References: <B3BB2565B39146A19ED745475660C165@EU.corp.clearwire.com>
	<8eea04080909231013v4309f602m40a58107fa0c5aa0@mail.gmail.com>
Message-ID: <290EF89F13F04F4E924BB235A46D18F1A6B80F@MLBMXUS2.cs.myharris.net>

So as long as your router is correctly mapping the IP PREC to the COS (802.1P field), it sounds like it might help.  These are 802.1Q tagged packets on the wireless, right?

Chuck


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jon Simola
Sent: Wednesday, September 23, 2009 1:13 PM
To: Rens
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ospf hellos


On Wed, Sep 23, 2009 at 7:35 AM, Rens <rens at autempspourmoi.be> wrote:

> Is there a way to prioritize ospf hello packets with 802.1p?

They are by default. See
http://www.cisco.com/en/US/tech/tk543/tk544/technologies_tech_note09186a0080094612.shtml

"Cisco IOS assigns an IP precedence of 6 to routing protocol packets
on the control plane. As noted by RFC 791, "The Internetwork Control
designation is intended for use by gateway control originators only."
Specifically, Cisco IOS marks these IP-based control packets: Open
Shortest Path First (OSPF), Routing Information Protocol (RIP),
Enhanced Interior Gateway Routing Protocol (EIGRP) hellos, and
keepalives. Telnet packets to and from the router also receive an IP
precedence value of 6. The assigned value remains with the packets
when the output interface transmits them into the network."

-- 
Jon
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From jsahala at gmail.com  Wed Sep 23 15:09:31 2009
From: jsahala at gmail.com (joshua sahala)
Date: Wed, 23 Sep 2009 13:09:31 -0600
Subject: [c-nsp] OSPF to ISIS migartion
In-Reply-To: <8bb137f40909230050vce3c824mc31113a20bfde129@mail.gmail.com>
References: <8bb137f40909230050vce3c824mc31113a20bfde129@mail.gmail.com>
Message-ID: <4b8f66d70909231209q78d0c747scdfde5f19b6842c8@mail.gmail.com>

On Wed, Sep 23, 2009 at 1:50 AM, jack daniels <jckdaniels12 at gmail.com> wrote:
[cut]
> WHAT CONSIDERATIONS TO KEEP IN MIND BEFORE MIGRATION.


as others have shared, vijay's presentation and methodology were spot on:
   - have ALL of your configurations pre-written/staged/tested
   - have a well organised plan of what order you will touch
everything that is being converted,
       or clear boundaries if you have to do it in stages so that
nothing is missed
   - execute the plan
   - verify the config on every device that was supposed to be touched

i've gone through the dance two times now (and preparing for a third
^_^ ) and haven't had any issues beyond lack of vendor support (cisco)
for the protocol.

wrt to the poster who said "just run ospfv3", i would disagree:  you
are adding significant complexity by running yet another routing
protocol (yarp?!?!) across the infrastructure, as well as adding
operational overhead.  in one of the two cases i've converted, it was
largely because we didn't want to run two distinct igps, and is-is is
a single and arguably simpler protocol  (<insert rant about the
simplicity of tlv versus lsa and size of code-base>)

my $0.02usd
/joshua
-- 
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
        - Douglas Adams -

From gert at greenie.muc.de  Wed Sep 23 15:17:20 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 23 Sep 2009 21:17:20 +0200
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Tunnels
	Vulnerability
In-Reply-To: <200909231215.tunnels@psirt.cisco.com>
References: <200909231215.tunnels@psirt.cisco.com>
Message-ID: <20090923191720.GC1508@greenie.muc.de>

Hi Cisco PSIRT (and c-nsp),

this one is specifically making me unhappy:

On Wed, Sep 23, 2009 at 12:15:00PM -0400, Cisco Systems Product Security Incident Response Team wrote:
> Cisco Security Advisory: Cisco IOS Software Tunnels Vulnerability
[..]
> +-------------------------------------------------------------------+
> |   Major    |          Availability of Repaired Releases           |
> |  Release   |                                                      |
> |------------+------------------------------------------------------|
> | 12.0       | Vulnerable; first fixed in 12.4      |               |
> |------------+--------------------------------------+---------------|
> | 12.1       | Vulnerable; first fixed in 12.4      |               |
> |------------+--------------------------------------+---------------|
> | 12.2       | Vulnerable; first fixed in 12.4      |               |
> |------------+--------------------------------------+---------------|
> | 12.3       | Vulnerable; first fixed in 12.4      |               |
> |------------+--------------------------------------+---------------|


What exactly does this mean?

 - there will never be a fixed 12.0, 12.1, 12.2 or 12.3 IOS, and we
   have to upgrade all routers to 12.4 IOS, which is very likely to
   require DRAM and Flash upgrades, and in many cases will mean "end of
   the affected device, forklift upgrade" (because there might not even
   *be* a 12.4 IOS)?

   [Yes, we could turn off all tunneling, but the tunnels are part of
   our 'wash-this-traffic' IDS/IDP solution, and I don't want to lose
   that functionality]

 - 12.0-fixed, 12.1-fixed, 12.2-fixed, 12.3-fixed will be shipped later?


If someone is listening: please provide at least fixed 12.2 and 12.3 
IOS versions, as this is quite likely going to be a LARGE installed
base of now-very-unhappy customers.  12.0 and 12.1 would be nice as well,
of course.


Also, another question remains:  the "malformed GRE packet" - does it
have to contain proper tunnel src + tunnel dst IP addresses (in which
cases this is easy to mitigate at our borders and with customer-facing
uRPF), or is it sufficient if the GRE packet has a destination address 
that is configured "anywhere on the box", and the source address doesn't 
matter?  This is not fully clear from the mitigation companion document.

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090923/d70994a4/attachment.bin>

From wgarvin at cisco.com  Wed Sep 23 16:06:40 2009
From: wgarvin at cisco.com (Wendy Garvin)
Date: Wed, 23 Sep 2009 13:06:40 -0700
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Tunnels
	Vulnerability
In-Reply-To: <20090923191720.GC1508@greenie.muc.de>
References: <200909231215.tunnels@psirt.cisco.com>
	<20090923191720.GC1508@greenie.muc.de>
Message-ID: <4ABA7FD0.2000905@cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Gert,

Gert Doering wrote:
> What exactly does this mean?
> 
>  - there will never be a fixed 12.0, 12.1, 12.2 or 12.3 IOS, and we
>    have to upgrade all routers to 12.4 IOS, which is very likely to
>    require DRAM and Flash upgrades, and in many cases will mean "end of
>    the affected device, forklift upgrade" (because there might not even
>    *be* a 12.4 IOS)?

Each of these releases life cycle is documented in our End of Life
announcements.

12.0:
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8802/ps1828/prod_end-of-life_notice0900aecd80563fea.html

12.1:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/prod_eol_notice09186a008032d55c.html

12.2:
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8802/ps6969/ps1835/ps4032/prod_end-of-life_notice0900aecd80330813.html

12.3:
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8802/ps6947/ps5187/prod_end-of-life_notice0900aecd8052e110.html


12.2 and 12.3 have reached their "End of Software Maintenance Release
Date" which means we will no longer be releasing scheduled updates.
However, they have not reached their last date of support, which means
you can still call in and receive assistance from the TAC. If the TAC
cannot assist you in deploying workarounds or upgrading to a supported
version of software, they can work with your account team to request a
rebuild of 12.2 or 12.3.

However, since those releases are past their End of Life dates, and
approaching Last Date of Support, TAC, your account team and PSIRT will
all recommend you start work on a plan to upgrade your software, and if
needed your hardware, to a supported release. 12.0 software came out
over 10 years ago, and in order to keep our commitment to give you
secure software, we must stop supporting stuff this old. It doesn't have
the same architecture or support for quality coding and secure features
that the later releases have.


>    [Yes, we could turn off all tunneling, but the tunnels are part of
>    our 'wash-this-traffic' IDS/IDP solution, and I don't want to lose
>    that functionality]
> 
>  - 12.0-fixed, 12.1-fixed, 12.2-fixed, 12.3-fixed will be shipped later?
> 
> 
> If someone is listening: please provide at least fixed 12.2 and 12.3 
> IOS versions, as this is quite likely going to be a LARGE installed
> base of now-very-unhappy customers.  12.0 and 12.1 would be nice as well,
> of course.

We are indeed listening. We will consider requests for 12.2 or 12.3
software on a case by case basis, but we will not be releasing that
software to a wide distribution. I urge you to work with support staff
to move to a more current release.

> Also, another question remains:  the "malformed GRE packet" - does it
> have to contain proper tunnel src + tunnel dst IP addresses (in which
> cases this is easy to mitigate at our borders and with customer-facing
> uRPF), or is it sufficient if the GRE packet has a destination address 
> that is configured "anywhere on the box", and the source address doesn't 
> matter?  This is not fully clear from the mitigation companion document.

The source and destination address must be the configured tunnel
addresses. The source address does matter, but it is possible to spoof
it. The destination address cannot be any address on the box, it must be
the configured destination address. However, you must take into account
that the source address could be spoofed.

Thanks,

- -Wendy

Wendy Garvin
Cisco PSIRT
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq6f9AACgkQz/q+G4BEr214ugCgg6Wc7G6/nrpPAeq6CoABIjz8
qJoAnjhDiTHNmeWYmLWEWV04OXTwjKXD
=ogYR
-----END PGP SIGNATURE-----

From rgolodner at infratection.com  Wed Sep 23 16:52:04 2009
From: rgolodner at infratection.com (Richard Golodner)
Date: Wed, 23 Sep 2009 15:52:04 -0500
Subject: [c-nsp] Proxy Registered Route Object ....
Message-ID: <1253739124.13242.27.camel@Andromeda>

	If someone could hip me off list as to what a Proxy Registered Route
Object is, I would be grateful. 
	Google has presented too much information for me to glean through right
now.	
	It seems to be a favorite way to do something. I just can't figure out
what that may be. The routes I am looking at do not belong to people who
observe good net etiquette.
	thank you, Richard


From gert at greenie.muc.de  Wed Sep 23 16:47:57 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 23 Sep 2009 22:47:57 +0200
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Tunnels
	Vulnerability
In-Reply-To: <4ABA7FD0.2000905@cisco.com>
References: <200909231215.tunnels@psirt.cisco.com>
	<20090923191720.GC1508@greenie.muc.de> <4ABA7FD0.2000905@cisco.com>
Message-ID: <20090923204757.GD1508@greenie.muc.de>

Hi,

On Wed, Sep 23, 2009 at 01:06:40PM -0700, Wendy Garvin wrote:
> Gert Doering wrote:
> > What exactly does this mean?
> > 
> >  - there will never be a fixed 12.0, 12.1, 12.2 or 12.3 IOS, and we
> >    have to upgrade all routers to 12.4 IOS, which is very likely to
> >    require DRAM and Flash upgrades, and in many cases will mean "end of
> >    the affected device, forklift upgrade" (because there might not even
> >    *be* a 12.4 IOS)?
> 
> Each of these releases life cycle is documented in our End of Life
> announcements.
[..]

Clear words.  Unhappy customer.

(Going to 12.4 is painful enough, due to the necessary feature/bug testing
required.  But what is much worse is "hardware replacements", due to 
hardware that's no longer supported - like various NPEs chugging happily
along in our network.  Spending money on forklift upgrades for *working*
hardware due to security bugs in the OS is just not going to make The 
People That Make Decisions About Money very happy with This Vendor).


> 12.2 and 12.3 have reached their "End of Software Maintenance Release
> Date" which means we will no longer be releasing scheduled updates.
> However, they have not reached their last date of support, which means
> you can still call in and receive assistance from the TAC. If the TAC
> cannot assist you in deploying workarounds or upgrading to a supported
> version of software, they can work with your account team to request a
> rebuild of 12.2 or 12.3.

Been through that with 12.2S.  Takes an eternity plus four months, and is
not a way to handle security issues.


[..]
> It doesn't have the same architecture or support for quality coding 
> and secure features that the later releases have.

We *are* talking about IOS, are we?  Monolithic, no memory protection,
no restartable processes, no software updates without reboots, helluva
lot of "surprise features" in 12.4T, etc.?

"quality coding", good joke.


[..]
> We are indeed listening. We will consider requests for 12.2 or 12.3
> software on a case by case basis, but we will not be releasing that
> software to a wide distribution. I urge you to work with support staff
> to move to a more current release.

See above.  "Case by case" upgrades are just not good enough for such
a widespread bug that affects everything Cisco has ever built.


[..]
> The source and destination address must be the configured tunnel
> addresses. The source address does matter, but it is possible to spoof
> it. The destination address cannot be any address on the box, it must be
> the configured destination address. However, you must take into account
> that the source address could be spoofed.

Now *this* is certainly good news.  Since the devices in question (which
can't easily be upgraded to 12.4) only have a single tunnel with a 
tunnel destination that is inside our network, anti-spoofing ACLs to
"peers and upstreams" are already in place, and customers get uRPF 
anyway.

So we're just not upgrading, and when the hardware breaks, we'll decide
what to buy as a replacement.

gert


-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090923/d51d49d0/attachment-0001.bin>

From ml at kenweb.org  Wed Sep 23 17:13:12 2009
From: ml at kenweb.org (ML)
Date: Wed, 23 Sep 2009 17:13:12 -0400
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software
	Tunnels	Vulnerability
In-Reply-To: <20090923204757.GD1508@greenie.muc.de>
References: <200909231215.tunnels@psirt.cisco.com>	<20090923191720.GC1508@greenie.muc.de>
	<4ABA7FD0.2000905@cisco.com> <20090923204757.GD1508@greenie.muc.de>
Message-ID: <4ABA8F68.8050808@kenweb.org>


> [..]
>> The source and destination address must be the configured tunnel
>> addresses. The source address does matter, but it is possible to spoof
>> it. The destination address cannot be any address on the box, it must be
>> the configured destination address. However, you must take into account
>> that the source address could be spoofed.
> 
> Now *this* is certainly good news.  Since the devices in question (which
> can't easily be upgraded to 12.4) only have a single tunnel with a 
> tunnel destination that is inside our network, anti-spoofing ACLs to
> "peers and upstreams" are already in place, and customers get uRPF 
> anyway.
> 
> So we're just not upgrading, and when the hardware breaks, we'll decide
> what to buy as a replacement.
> 
> gert


I've read this passage multiple times and I want to clear this up.

The malicious packet *must* contain the actual tunnel source and 
destination address.  Anything else and the attack is ineffective.

-ML


From wgarvin at cisco.com  Wed Sep 23 17:40:04 2009
From: wgarvin at cisco.com (Wendy Garvin)
Date: Wed, 23 Sep 2009 14:40:04 -0700
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Tunnels
	Vulnerability
In-Reply-To: <20090923204757.GD1508@greenie.muc.de>
References: <200909231215.tunnels@psirt.cisco.com>
	<20090923191720.GC1508@greenie.muc.de> <4ABA7FD0.2000905@cisco.com>
	<20090923204757.GD1508@greenie.muc.de>
Message-ID: <4ABA95B4.3090607@cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gert,

> Clear words.  Unhappy customer.
> 
> (Going to 12.4 is painful enough, due to the necessary feature/bug testing
> required.  But what is much worse is "hardware replacements", due to 
> hardware that's no longer supported - like various NPEs chugging happily
> along in our network.  Spending money on forklift upgrades for *working*
> hardware due to security bugs in the OS is just not going to make The 
> People That Make Decisions About Money very happy with This Vendor).

Our PSIRT executives have seen this feedback, and we've passed it
directly to the engineering executives responsible for the End of Life
policies. I encourage you to contact TAC or your account team, as that
gets you help about your specific network, hardware and software, as
well as another advocate and voice within Cisco.

Thanks,

- -Wendy

Wendy Garvin
Cisco PSIRT
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq6lbQACgkQz/q+G4BEr23NkACglZh8V4GWRfU3nr3jWl6HuH6T
AjgAoIBI+r3Akx2pHcj0ky4spQhYAoP/
=voCx
-----END PGP SIGNATURE-----

From gsgranados at comcast.net  Wed Sep 23 18:07:45 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Wed, 23 Sep 2009 15:07:45 -0700
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
Message-ID: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>

Hi,
    To add more to the comments against the new download management system, 
the download screens are totally inaccessible to users that require a screen 
reader.  You can get as far as selecting the software to download, accepting 
the far to many terms and conditions and then once you select download now a 
java based page seems to open that is written in such a way that both JFW 
and Window-Eyes can't make out any usable controls. Clearly Cisco is losing 
interest in providing products and services to the US Government among 
others since new components on their web pages as well as new UI elements on 
devices like the ASA are not in step with accessibility requirements. I can 
say that Vendors F and J don't have nearly the accessibility issues of Cisco 
lately so at least the company I work for will be buying new products from 
someone else than Cisco from now on until this is addressed.

    All that aside, does anyone have a non Cisco pointer or back way in to 
Cisco's site that I can use to download the latest V5.X windows XP VPN 
client?  Any pointers would be appreciated.

Thanks
Scott



From jsahala at gmail.com  Wed Sep 23 18:28:46 2009
From: jsahala at gmail.com (joshua sahala)
Date: Wed, 23 Sep 2009 16:28:46 -0600
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>
Message-ID: <4b8f66d70909231528w63f4f9f6s7f41d99e5547c842@mail.gmail.com>

On Wed, Sep 23, 2009 at 4:07 PM, Scott Granados <gsgranados at comcast.net> wrote:
[cut]
>
> ? All that aside, does anyone have a non Cisco pointer or back way in to
> Cisco's site that I can use to download the latest V5.X windows XP VPN
> client? ?Any pointers would be appreciated.

check out the greasemonkey firefox plugin and script:
https://addons.mozilla.org/en-US/firefox/addon/748
http://userscripts.org/scripts/show/58082

also, i'd recommend opening a tac case and rating the download process
as poor ^_^

/joshua
-- 
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
        - Douglas Adams -

From jsahala at gmail.com  Wed Sep 23 18:33:00 2009
From: jsahala at gmail.com (joshua sahala)
Date: Wed, 23 Sep 2009 16:33:00 -0600
Subject: [c-nsp] Proxy Registered Route Object ....
In-Reply-To: <1253739124.13242.27.camel@Andromeda>
References: <1253739124.13242.27.camel@Andromeda>
Message-ID: <4b8f66d70909231533v7b55be86p9afb44cda747a81b@mail.gmail.com>

richard,

On Wed, Sep 23, 2009 at 2:52 PM, Richard Golodner
<rgolodner at infratection.com> wrote:
> ? ? ? ?If someone could hip me off list as to what a Proxy Registered Route
> Object is, I would be grateful.
> ? ? ? ?Google has presented too much information for me to glean through right
> now.
> ? ? ? ?It seems to be a favorite way to do something. I just can't figure out
> what that may be. The routes I am looking at do not belong to people who
> observe good net etiquette.
> ? ? ? ?thank you, Richard


a proxy registered object is just that:  someone (a provider)
registered a route object on behalf of someone else (usually their
customer)

level3 (and others) generate their customer-edge routing policies
automagically based upon the objects...if there isn't an object for
that customer prefix, they will create one in their database.  this
allows their less-clueful/poor-netizen customers to remain ignorant of
the process

/joshua
-- 
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
        - Douglas Adams -

From jsimola at gmail.com  Wed Sep 23 19:24:08 2009
From: jsimola at gmail.com (Jon Simola)
Date: Wed, 23 Sep 2009 16:24:08 -0700
Subject: [c-nsp] NBAR + QoS - policing kills class-default traffic
In-Reply-To: <E222D1E6A503BD4B815A3B6FCC50311B76561518D5@USPDXEXC001.vestas.net>
References: <E222D1E6A503BD4B815A3B6FCC50311B76561518D5@USPDXEXC001.vestas.net>
Message-ID: <8eea04080909231624x22b6a22al4ba4bc73690524a2@mail.gmail.com>

On Tue, Sep 22, 2009 at 2:07 PM, Matthew White <mawhi at vestas.com> wrote:

> The policy polices HULU and PANDORA, counters don't increment for YOUTUBE (and doesn't get policed) and after 3 or 4 minutes ALL web traffic is policed. Has anyone seen this behavior before?

Counters not incrementing for Youtube might be easy, browsers are
redirected to a different site and end up streaming from s.ytimg.com
as an example.

As for the rest, Petr Lapukhov posted a brief article at
http://blog.internetworkexpert.com/2008/11/04/using-nbar-for-http-url-filtering/
and one of the last things he mentions is "NBAR engine is buggy :)
Sometimes you may found your class matches much more traffic than you
wanted and drops really important packets. Ooops! This happens all the
times."

-- 
Jon

From jared at puck.nether.net  Wed Sep 23 19:27:10 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 23 Sep 2009 19:27:10 -0400
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>
Message-ID: <4F5D9C2A-1FB8-4FF2-A91C-213290CB018B@puck.nether.net>

You really need to communicate this to GSA and perhaps DoJ.  Many web  
developers do not take these issues into account, it's sad to continue  
to see the same regression of website access.  I would love to see a  
way to access the downloads that does not require javascript (it can  
require cookies or HTTP Auth).

	- Jared

On Sep 23, 2009, at 6:07 PM, Scott Granados wrote:

> Hi,
>   To add more to the comments against the new download management  
> system, the download screens are totally inaccessible to users that  
> require a screen reader.  You can get as far as selecting the  
> software to download, accepting the far to many terms and conditions  
> and then once you select download now a java based page seems to  
> open that is written in such a way that both JFW and Window-Eyes  
> can't make out any usable controls. Clearly Cisco is losing interest  
> in providing products and services to the US Government among others  
> since new components on their web pages as well as new UI elements  
> on devices like the ASA are not in step with accessibility  
> requirements. I can say that Vendors F and J don't have nearly the  
> accessibility issues of Cisco lately so at least the company I work  
> for will be buying new products from someone else than Cisco from  
> now on until this is addressed.
>
>   All that aside, does anyone have a non Cisco pointer or back way  
> in to Cisco's site that I can use to download the latest V5.X  
> windows XP VPN client?  Any pointers would be appreciated.
>
> Thanks
> Scott
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From gsgranados at comcast.net  Wed Sep 23 19:38:50 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Wed, 23 Sep 2009 16:38:50 -0700
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>
	<4F5D9C2A-1FB8-4FF2-A91C-213290CB018B@puck.nether.net>
Message-ID: <03d901ca3ca7$068ed770$2208120a@am.thmulti.com>

Hi,
I plan on mentioning this to a few contacts.  I don't think much will come 
of it what with the blind community being such a small subset of the market 
(far below the noise levels) but it can't hurt. It just surprises me that a 
company would show such lack of concern for their products and supporting 
content. There are many on this list who manage very large networks and 
you'd think their vendor would listen to their complaints.  Might be wishful 
thinking though. I wonder if anyone besides sales and marketing droids 
actually finds the new download center better let alone usable?

Thanks
Scott


----- Original Message ----- 
From: "Jared Mauch" <jared at puck.nether.net>
To: "Scott Granados" <gsgranados at comcast.net>
Cc: <cisco-nsp at puck.nether.net>
Sent: Wednesday, September 23, 2009 4:27 PM
Subject: Re: [c-nsp] Download manager hell and latest Windows VPN Client?


> You really need to communicate this to GSA and perhaps DoJ.  Many web 
> developers do not take these issues into account, it's sad to continue  to 
> see the same regression of website access.  I would love to see a  way to 
> access the downloads that does not require javascript (it can  require 
> cookies or HTTP Auth).
>
> - Jared
>
> On Sep 23, 2009, at 6:07 PM, Scott Granados wrote:
>
>> Hi,
>>   To add more to the comments against the new download management 
>> system, the download screens are totally inaccessible to users that 
>> require a screen reader.  You can get as far as selecting the  software 
>> to download, accepting the far to many terms and conditions  and then 
>> once you select download now a java based page seems to  open that is 
>> written in such a way that both JFW and Window-Eyes  can't make out any 
>> usable controls. Clearly Cisco is losing interest  in providing products 
>> and services to the US Government among others  since new components on 
>> their web pages as well as new UI elements  on devices like the ASA are 
>> not in step with accessibility  requirements. I can say that Vendors F 
>> and J don't have nearly the  accessibility issues of Cisco lately so at 
>> least the company I work  for will be buying new products from someone 
>> else than Cisco from  now on until this is addressed.
>>
>>   All that aside, does anyone have a non Cisco pointer or back way  in to 
>> Cisco's site that I can use to download the latest V5.X  windows XP VPN 
>> client?  Any pointers would be appreciated.
>>
>> Thanks
>> Scott
>>
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


From streiner at cluebyfour.org  Wed Sep 23 19:52:36 2009
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Wed, 23 Sep 2009 19:52:36 -0400 (EDT)
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>
Message-ID: <Pine.LNX.4.64.0909231830010.32526@whammy.cluebyfour.org>

On Wed, 23 Sep 2009, Scott Granados wrote:

>   To add more to the comments against the new download management system, 
> the download screens are totally inaccessible to users that require a screen 
> reader.  You can get as far as selecting the software to download, accepting 
> the far to many terms and conditions and then once you select download now a 
> java based page seems to open that is written in such a way that both JFW and 
> Window-Eyes can't make out any usable controls.
>
>   All that aside, does anyone have a non Cisco pointer or back way in to 
> Cisco's site that I can use to download the latest V5.X windows XP VPN 
> client?  Any pointers would be appreciated.

I haven't really looked at it from the point of accessibility, but that is 
definitely a good point and a valid concern.

My main argument against the download manager applet is that I hate 
dealing with several layers of dependency hell with Java.  Does the 
download manager work with the Java plugin in my web browser when that 
plugin is based on different JRE versions?  Also, there seems to be this 
movement by some vendors to replace simple processes (an HTTP or FTP 
download) with something bulkier, like a Java applet, presumably because 
it looks prettier.  Putting my business hat on for a second, I don't 
understand the value proposition.

Echoing Scott's request, if there is an 'off the menu' way to still access 
software downloads the old way, I'm all for it.

jms

From wmaton at ryouko.imsb.nrc.ca  Wed Sep 23 19:56:45 2009
From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor)
Date: Wed, 23 Sep 2009 19:56:45 -0400 (EDT)
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <Pine.LNX.4.64.0909231830010.32526@whammy.cluebyfour.org>
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>
	<Pine.LNX.4.64.0909231830010.32526@whammy.cluebyfour.org>
Message-ID: <Pine.LNX.4.64.0909231949450.31299@ryouko.imsb.nrc.ca>

On Wed, 23 Sep 2009, Justin M. Streiner wrote:

>>   All that aside, does anyone have a non Cisco pointer or back way in to 
>> Cisco's site that I can use to download the latest V5.X windows XP VPN 
>> client?  Any pointers would be appreciated.
[snip]
> Echoing Scott's request, if there is an 'off the menu' way to still access 
> software downloads the old way, I'm all for it.

Accessibility issues aside (perfectly valid points as well), I too have 
just today experienced JAVA 'Download Manager' hell.  I did voice my 
disapproval through the form there and good a polite response back 
pointing me to the usual JAVA version caveats.  I responded back (equally 
politely) that I did test my browser's JAVA plugin and it claimed I was 
compliant.  The JAVA applet still failed to load.

I subsequently coaxed the JAVA console out of hiding and asked for the log 
and traceback, enclosed that too.

In the meantime, I asked my friendly neighbourhood SE about 
download alternatives.  He suggested I should open a TAC case.  Oh dear. 
I wonder how many of those are being opened by others as I type this....?

wfms

From sethm at rollernet.us  Wed Sep 23 21:28:45 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 23 Sep 2009 18:28:45 -0700
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <Pine.LNX.4.64.0909231949450.31299@ryouko.imsb.nrc.ca>
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>	<Pine.LNX.4.64.0909231830010.32526@whammy.cluebyfour.org>
	<Pine.LNX.4.64.0909231949450.31299@ryouko.imsb.nrc.ca>
Message-ID: <4ABACB4D.5000009@rollernet.us>

William F. Maton Sotomayor wrote:
> On Wed, 23 Sep 2009, Justin M. Streiner wrote:
> 
>>>   All that aside, does anyone have a non Cisco pointer or back way in
>>> to Cisco's site that I can use to download the latest V5.X windows XP
>>> VPN client?  Any pointers would be appreciated.
> [snip]
>> Echoing Scott's request, if there is an 'off the menu' way to still
>> access software downloads the old way, I'm all for it.
> 
> Accessibility issues aside (perfectly valid points as well), I too have
> just today experienced JAVA 'Download Manager' hell.  I did voice my
> disapproval through the form there and good a polite response back
> pointing me to the usual JAVA version caveats.  I responded back
> (equally politely) that I did test my browser's JAVA plugin and it
> claimed I was compliant.  The JAVA applet still failed to load.
> 
> I subsequently coaxed the JAVA console out of hiding and asked for the
> log and traceback, enclosed that too.
> 
> In the meantime, I asked my friendly neighbourhood SE about download
> alternatives.  He suggested I should open a TAC case.  Oh dear. I wonder
> how many of those are being opened by others as I type this....?
> 

Stop downloading completely; everyone just open TAC cases from now on
when you need an image. That might make it on someone's radar.

~Seth

From BBlackford at nwresd.k12.or.us  Wed Sep 23 22:26:22 2009
From: BBlackford at nwresd.k12.or.us (Bill Blackford)
Date: Wed, 23 Sep 2009 19:26:22 -0700
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS
	Software	Tunnels	Vulnerability
In-Reply-To: <4ABA8F68.8050808@kenweb.org>
References: <200909231215.tunnels@psirt.cisco.com>
	<20090923191720.GC1508@greenie.muc.de>	<4ABA7FD0.2000905@cisco.com>
	<20090923204757.GD1508@greenie.muc.de>,<4ABA8F68.8050808@kenweb.org>
Message-ID: <6069A203FD01884885C037F81DD750801722C59476@wsc-mail-01.intra.nwresd.k12.or.us>

Can I ask a stupid question? What about the cat6.5k that ceilings out at 12.2(33)SXI2? Is this special case?

-b
________________________________________
From: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net] On Behalf Of ML [ml at kenweb.org]
Sent: Wednesday, September 23, 2009 2:13 PM
To: Gert Doering
Cc: Cisco Systems Product Security Incident Response Team; cisco-nsp at puck.nether.net; Wendy Garvin
Subject: Re: [c-nsp] Cisco Security Advisory: Cisco IOS Software        Tunnels Vulnerability

> [..]
>> The source and destination address must be the configured tunnel
>> addresses. The source address does matter, but it is possible to spoof
>> it. The destination address cannot be any address on the box, it must be
>> the configured destination address. However, you must take into account
>> that the source address could be spoofed.
>
> Now *this* is certainly good news.  Since the devices in question (which
> can't easily be upgraded to 12.4) only have a single tunnel with a
> tunnel destination that is inside our network, anti-spoofing ACLs to
> "peers and upstreams" are already in place, and customers get uRPF
> anyway.
>
> So we're just not upgrading, and when the hardware breaks, we'll decide
> what to buy as a replacement.
>
> gert


I've read this passage multiple times and I want to clear this up.

The malicious packet *must* contain the actual tunnel source and
destination address.  Anything else and the attack is ineffective.

-ML

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From BBlackford at nwresd.k12.or.us  Wed Sep 23 23:11:28 2009
From: BBlackford at nwresd.k12.or.us (Bill Blackford)
Date: Wed, 23 Sep 2009 20:11:28 -0700
Subject: [c-nsp] Cisco Security Advisory: Cisco
	IOS	Software	Tunnels	Vulnerability
In-Reply-To: <6069A203FD01884885C037F81DD750801722C59476@wsc-mail-01.intra.nwresd.k12.or.us>
References: <200909231215.tunnels@psirt.cisco.com>
	<20090923191720.GC1508@greenie.muc.de>	<4ABA7FD0.2000905@cisco.com>
	<20090923204757.GD1508@greenie.muc.de>, <4ABA8F68.8050808@kenweb.org>,
	<6069A203FD01884885C037F81DD750801722C59476@wsc-mail-01.intra.nwresd.k12.or.us>
Message-ID: <6069A203FD01884885C037F81DD750801722C5947A@wsc-mail-01.intra.nwresd.k12.or.us>

Sorry to reply to my own post. Someone on the list contacted me off-list to point out that this does *not* include the "12.2.S" release.
I apologize to the group.


-b


________________________________________
From: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net] On Behalf Of Bill Blackford [BBlackford at nwresd.k12.or.us]
Sent: Wednesday, September 23, 2009 7:26 PM
To: ML; Gert Doering
Cc: Cisco Systems Product Security Incident Response Team; cisco-nsp at puck.nether.net; Wendy Garvin
Subject: Re: [c-nsp] Cisco Security Advisory: Cisco IOS Software        Tunnels Vulnerability

Can I ask a stupid question? What about the cat6.5k that ceilings out at 12.2(33)SXI2? Is this special case?

-b
________________________________________
From: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net] On Behalf Of ML [ml at kenweb.org]
Sent: Wednesday, September 23, 2009 2:13 PM
To: Gert Doering
Cc: Cisco Systems Product Security Incident Response Team; cisco-nsp at puck.nether.net; Wendy Garvin
Subject: Re: [c-nsp] Cisco Security Advisory: Cisco IOS Software        Tunnels Vulnerability

> [..]
>> The source and destination address must be the configured tunnel
>> addresses. The source address does matter, but it is possible to spoof
>> it. The destination address cannot be any address on the box, it must be
>> the configured destination address. However, you must take into account
>> that the source address could be spoofed.
>
> Now *this* is certainly good news.  Since the devices in question (which
> can't easily be upgraded to 12.4) only have a single tunnel with a
> tunnel destination that is inside our network, anti-spoofing ACLs to
> "peers and upstreams" are already in place, and customers get uRPF
> anyway.
>
> So we're just not upgrading, and when the hardware breaks, we'll decide
> what to buy as a replacement.
>
> gert


I've read this passage multiple times and I want to clear this up.

The malicious packet *must* contain the actual tunnel source and
destination address.  Anything else and the attack is ineffective.

-ML

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From pekkas at netcore.fi  Thu Sep 24 00:59:44 2009
From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 24 Sep 2009 07:59:44 +0300 (EEST)
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Tunnels
 Vulnerability
In-Reply-To: <200909231215.tunnels@psirt.cisco.com>
References: <200909231215.tunnels@psirt.cisco.com>
Message-ID: <alpine.LRH.2.00.0909240756180.29157@netcore.fi>

On Wed, 23 Sep 2009, Cisco Systems Product Security Incident Response Team wrote:
> Cisco IOS Software and configured for Generic Routing Encapsulation
> (GRE), IPinIP, Generic Packet Tunneling in IPv6 or IPv6 over IP
> tunnels with Cisco Express Forwarding enabled. The Cisco IOS Point to
> Point Tunneling Protocol (PPTP) feature creates GRE tunnels that are
> transparent to the user. Therefore systems configured for PPTP are
> also vulnerable.
>
> The Cisco multicast Virtual Private Network (MVPN) feature also
> creates GRE tunnels that are transparent to the user, however MVPN
> configurations are not vulnerable, unless there are other tunnels
> that are configured explicitly.

PIM Register-encapsulation/decapsulation creates TunnelX-interfaces 
dynamically and transparently and it's essentially IP-in-IP.  I'd 
appreciate a clarification whether routers running as PIM DR or PIM RP 
are affected.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From frosya84 at mail.ru  Thu Sep 24 03:15:49 2009
From: frosya84 at mail.ru (=?koi8-r?Q?=EF=CC=D8=C7=C1_=F2=D5=D6=C1=CE=D3=CB=C1=D1?=)
Date: Thu, 24 Sep 2009 11:15:49 +0400
Subject: [c-nsp]
	=?koi8-r?b?SW50ZXItQVMgTDJWUE4gcmVkdW5kYW5jeSwgb3B0aW9u?=
	=?koi8-r?b?IEIgKFJ1emhhbnNrYXlhIE9sZ2Ep?=
In-Reply-To: <6b300f5d0909230512o17b8dbd6t6e64554a8ed8e33b@mail.gmail.com>
References: <6b300f5d0909230512o17b8dbd6t6e64554a8ed8e33b@mail.gmail.com>
Message-ID: <E1MqiYP-0005at-00.frosya84-mail-ru@f179.mail.ru>

Hello,

Thank You for book,
but approach proposed in it is for redundancy inside 1 AS, not between 2 AS.
I've seen it on cisco.com before..

Best regards,
Olga
-----Original Message-----
From: "Andrey 'sshd' Petrenko" <andy.petrenko at gmail.com>
To: ????? ????????? <frosya84 at mail.ru>
Date: Wed, 23 Sep 2009 15:12:55 +0300
Subject: Re: [c-nsp] Inter-AS L2VPN redundancy, option B (Ruzhanskaya Olga)

> Book MPLS Configuration on Cisco IOS Software.  Implementing Layer 2 VPNs
> over Inter-AS Topologies Using Layer 2 VPN Pseudo-Wire Switching.
> 
> 
> 23 ???????? 2009 ?. 11:10 ???????????? ????? ?????????
> <frosya84 at mail.ru>???????:
> 
> With best regards,
>      Andrey 'sshd' Petrenko
>      xmmp: sshd at jabber.org
>      gtalk: andy.petrenko at gmail.com
>      skype: andy.petrenko
>      web: http://sshd.by
> 
> 

From gert at greenie.muc.de  Thu Sep 24 03:24:48 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Thu, 24 Sep 2009 09:24:48 +0200
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software
	Tunnels	Vulnerability
In-Reply-To: <4ABA8F68.8050808@kenweb.org>
References: <200909231215.tunnels@psirt.cisco.com>
	<20090923191720.GC1508@greenie.muc.de> <4ABA7FD0.2000905@cisco.com>
	<20090923204757.GD1508@greenie.muc.de>
	<4ABA8F68.8050808@kenweb.org>
Message-ID: <20090924072448.GF1508@greenie.muc.de>

Hi,

On Wed, Sep 23, 2009 at 05:13:12PM -0400, ML wrote:
> The malicious packet *must* contain the actual tunnel source and 
> destination address.  Anything else and the attack is ineffective.

This is how I understood Wendy - and this makes this attack quite easy
to mitigate for us.  Actually, we don't need to mitigate anything on
all-but-two routers, as those have only a single tunnel with a destination
address that's inside our network, and a source address coming from a 
well-known block.

Infrastructure ACLs at the edge prevent packets to that destination
address, and anti-spoofing iACLs prevent packets with a source address
that would match the "tunnel destination".

Customer interfaces ALL have uRPF configured, so there is no way a packet
with a matching source address can enter our network.  Case closed.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090924/c9080fdc/attachment.bin>

From gert at greenie.muc.de  Thu Sep 24 03:38:39 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Thu, 24 Sep 2009 09:38:39 +0200
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <4F5D9C2A-1FB8-4FF2-A91C-213290CB018B@puck.nether.net>
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>
	<4F5D9C2A-1FB8-4FF2-A91C-213290CB018B@puck.nether.net>
Message-ID: <20090924073839.GI1508@greenie.muc.de>

Hi,

On Wed, Sep 23, 2009 at 07:27:10PM -0400, Jared Mauch wrote:
> You really need to communicate this to GSA and perhaps DoJ.  Many web  
> developers do not take these issues into account, it's sad to continue  
> to see the same regression of website access.  I would love to see a  
> way to access the downloads that does not require javascript (it can  
> require cookies or HTTP Auth).

I really can't understand what is so hard about FTP access.

Fill in a web form once, claim "yes, I'm no terrorist!", and then the
FTP servers put you into a "he's no terrorist, may download crypto 
software" group...

This is really "Internet 0.9" knowledge.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090924/d900d7c7/attachment-0001.bin>

From gert at greenie.muc.de  Thu Sep 24 03:26:26 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Thu, 24 Sep 2009 09:26:26 +0200
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS	Software	Tunnels
	Vulnerability
In-Reply-To: <6069A203FD01884885C037F81DD750801722C5947A@wsc-mail-01.intra.nwresd.k12.or.us>
References: <200909231215.tunnels@psirt.cisco.com>
	<20090923191720.GC1508@greenie.muc.de> <4ABA7FD0.2000905@cisco.com>
	<6069A203FD01884885C037F81DD750801722C5947A@wsc-mail-01.intra.nwresd.k12.or.us>
Message-ID: <20090924072626.GG1508@greenie.muc.de>

Hi,

On Wed, Sep 23, 2009 at 08:11:28PM -0700, Bill Blackford wrote:
> Sorry to reply to my own post. Someone on the list contacted me 
> off-list to point out that this does *not* include the "12.2.S" release.

Well, since there *is no* other IOS than 12.2 SR / 12.2 SX for the
Cat 6.5 / 7.6 boxes, it would be somewhat difficult to move to 12.4 here...

> I apologize to the group.

I can certainly understand the confusion caused by the IOS train splits...

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090924/235eed05/attachment.bin>

From abhishake00 at yahoo.com  Thu Sep 24 02:58:40 2009
From: abhishake00 at yahoo.com (abs)
Date: Wed, 23 Sep 2009 23:58:40 -0700 (PDT)
Subject: [c-nsp] closing ports
Message-ID: <997578.94458.qm@web53709.mail.re2.yahoo.com>

Hello all, 
I am new to this so please excuse my ignorance.

I am running the following version of IOS: Cisco IOS Software, 2800 Software (C2800NM-ADVENTERPRISEK9-M), Version 12.4(11)T, RELEASE SOFTWARE (fc2)

I recently made some changes to the config at which point a port scan on the router is showing all ports to be open.? I only want 80, 8080, and 22 to be open.? I know this is something very basic but I cannot seem to figure it out.? Here is my partial config.? Please let me know if additional information is required.? Thank you in advance.

==============================

ip nat inside source list 2 interface Cable-Modem0/0/0 overload
ip nat inside source list 4 interface Cable-Modem0/0/0 overload
ip nat inside source static tcp 192.168.2.210 8080 interface Cable-Modem0/0/0 8080
ip nat inside source static tcp 192.168.2.208 22 interface Cable-Modem0/0/0 22
ip nat inside source static tcp 192.168.2.208 80 interface Cable-Modem0/0/0 80

access-list 2 permit 192.168.2.0 0.0.0.255
access-list 2 deny?? any
access-list 4 permit 192.168.54.0 0.0.0.255
access-list 4 deny?? any

================ end config ================





      

From nick at inex.ie  Thu Sep 24 05:04:02 2009
From: nick at inex.ie (Nick Hilliard)
Date: Thu, 24 Sep 2009 10:04:02 +0100
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <20090924073839.GI1508@greenie.muc.de>
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>	<4F5D9C2A-1FB8-4FF2-A91C-213290CB018B@puck.nether.net>
	<20090924073839.GI1508@greenie.muc.de>
Message-ID: <4ABB3602.9030102@inex.ie>

On 24/09/2009 08:38, Gert Doering wrote:
> Fill in a web form once, claim "yes, I'm no terrorist!", and then the
> FTP servers put you into a "he's no terrorist, may download crypto
> software" group...
>
> This is really "Internet 0.9" knowledge.

Gert,

You're ignoring the possibility that people change over time.  What if a 
person was a regular joe soap on the day that they filled out this web 
form, but had become a terrorist within a short period of time?  How would 
your single form proposal cope with this, pray tell?  Filling in the 
terrorism / nuclear arms shipment / bioweapons form each time is designed 
precisely to deal with smart alecs who think that they can get around arms 
embargoes like this.

Nick

From wim.holemans at ua.ac.be  Thu Sep 24 05:33:50 2009
From: wim.holemans at ua.ac.be (Holemans Wim)
Date: Thu, 24 Sep 2009 11:33:50 +0200
Subject: [c-nsp] STP and RSTP interaction
Message-ID: <A9C0DC3E3383224B83C528B074390E8C12999E@xmail04.ad.ua.ac.be>

Until now we used standard STP in our network with changed diameter
parameters (diameters of 10,11,..)

We plan to migrate to RSTP and as far as I tell from reading about it,
this should be no problem if we start changing from the outside into the
core.

I now have to add a new part to our network and in this part I already
enabled RSTP. I'm still hesitating to couple both networks as I don't
have an idea how the RSTP part will interfere with the diameter of the
existing network. If I'm right the 'coupling' interface of the new
network will work in STP mode and the rest of the new network in RSTP.
How does do I count this new network when calculating the new diameter ?
Just as 1 switch ? Or do I count the full topology ? Anyone has done
this before and can comment on this ? Other suggestions, experiences
with the migration from STP to RSTP that may help ?

 

Greeting,  

 

Wim Holemans

Network Services University of  Antwerp

 


From gert at greenie.muc.de  Thu Sep 24 05:44:17 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Thu, 24 Sep 2009 11:44:17 +0200
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <4ABB3602.9030102@inex.ie>
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>
	<4F5D9C2A-1FB8-4FF2-A91C-213290CB018B@puck.nether.net>
	<20090924073839.GI1508@greenie.muc.de> <4ABB3602.9030102@inex.ie>
Message-ID: <20090924094417.GM1508@greenie.muc.de>

Hi,

On Thu, Sep 24, 2009 at 10:04:02AM +0100, Nick Hilliard wrote:
> On 24/09/2009 08:38, Gert Doering wrote:
> >Fill in a web form once, claim "yes, I'm no terrorist!", and then the
> >FTP servers put you into a "he's no terrorist, may download crypto
> >software" group...
> >
> >This is really "Internet 0.9" knowledge.
> 
> You're ignoring the possibility that people change over time.  What if a 
> person was a regular joe soap on the day that they filled out this web 
> form, but had become a terrorist within a short period of time?  How would 
> your single form proposal cope with this, pray tell?  Filling in the 
> terrorism / nuclear arms shipment / bioweapons form each time is designed 
> precisely to deal with smart alecs who think that they can get around arms 
> embargoes like this.

Well.  You sound very serious, but I'm *sure* that you're making fun of me.

(Of course, terrorists would never lie regarding the "I'm no terrorist!"
statement).

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090924/429b310f/attachment.bin>

From tomas at soitron.com  Thu Sep 24 06:41:56 2009
From: tomas at soitron.com (Daniska, Tomas)
Date: Thu, 24 Sep 2009 12:41:56 +0200
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <20090924094417.GM1508@greenie.muc.de>
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com><4F5D9C2A-1FB8-4FF2-A91C-213290CB018B@puck.nether.net><20090924073839.GI1508@greenie.muc.de>
	<4ABB3602.9030102@inex.ie> <20090924094417.GM1508@greenie.muc.de>
Message-ID: <6B43981C32F8464CB24CEE209DA32BD3025A2B5C@kenya.tronet.as>

hey... then I suggest launching the ftp/http client with --evilbit=0
option ;->

--

deejay


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Gert Doering
> Sent: Thursday, September 24, 2009 11:44 AM
> To: Nick Hilliard
> Cc: Gert Doering; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Download manager hell and latest Windows VPN
> Client?
> 
> Hi,
> 
> On Thu, Sep 24, 2009 at 10:04:02AM +0100, Nick Hilliard wrote:
> > On 24/09/2009 08:38, Gert Doering wrote:
> > >Fill in a web form once, claim "yes, I'm no terrorist!", and then
> the
> > >FTP servers put you into a "he's no terrorist, may download crypto
> > >software" group...
> > >
> > >This is really "Internet 0.9" knowledge.
> >
> > You're ignoring the possibility that people change over time.  What
> if a
> > person was a regular joe soap on the day that they filled out this
> web
> > form, but had become a terrorist within a short period of time?  How
> would
> > your single form proposal cope with this, pray tell?  Filling in the
> > terrorism / nuclear arms shipment / bioweapons form each time is
> designed
> > precisely to deal with smart alecs who think that they can get
around
> arms
> > embargoes like this.
> 
> Well.  You sound very serious, but I'm *sure* that you're making fun
of
> me.
> 
> (Of course, terrorists would never lie regarding the "I'm no
> terrorist!"
> statement).
> 
> gert
> --
> USENET is *not* the non-clickable part of WWW!
> 
> //www.muc.de/~gert/
> Gert Doering - Munich, Germany
> gert at greenie.muc.de
> fax: +49-89-35655025                        gert at net.informatik.tu-
> muenchen.de
> 
> 
> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 4452
> (20090924) __________
> 
> Tuto spravu preveril ESET NOD32 Antivirus.
> 
> http://www.eset.sk
> 
 

__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4452
(20090924) __________

Tuto spravu preveril ESET NOD32 Antivirus.

http://www.eset.sk
 

From tim at pelican.org  Thu Sep 24 05:57:17 2009
From: tim at pelican.org (Tim Franklin)
Date: Thu, 24 Sep 2009 09:57:17 +0000 (GMT)
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <20090924094417.GM1508@greenie.muc.de>
Message-ID: <1054545.01253786237276.JavaMail.root@jennyfur.pelican.org>

> Well.  You sound very serious, but I'm *sure* that you're making fun
> of me.
> 
> (Of course, terrorists would never lie regarding the "I'm no
> terrorist!"
> statement).

I think it's like convicting Al Capone of tax evasion.  You don't have to prove they did anything naughty with the software, just that they didn't tell the truth on the form.  The US Immigration people have a similar point of view, with their "are YOU anti-American?" pre-arrival form.

Personally, I think it just provides a Dawinian leg-up for the Bad People by weeding out the truly stupid from their ranks who would tell the truth to any such question ;)

Regards,
Tim.



From dr at cluenet.de  Thu Sep 24 07:25:13 2009
From: dr at cluenet.de (Daniel Roesen)
Date: Thu, 24 Sep 2009 13:25:13 +0200
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Network
	Time	Protocol Packet Vulnerability
In-Reply-To: <200909231215.ntp@psirt.cisco.com>
References: <200909231215.ntp@psirt.cisco.com>
Message-ID: <20090924112513.GA24608@srv03.cluenet.de>

On Wed, Sep 23, 2009 at 12:15:00PM -0400, Cisco Systems Product Security Incident Response Team wrote:
> Cisco IOS Software devices are vulnerable if they support NTPv4 and
> are configured for NTP operations.

Are NTP ACLs "ntp access-group ..." any help?


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0

From zivl at gilat.net  Thu Sep 24 07:36:56 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Thu, 24 Sep 2009 14:36:56 +0300
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <1054545.01253786237276.JavaMail.root@jennyfur.pelican.org>
References: <20090924094417.GM1508@greenie.muc.de>
	<1054545.01253786237276.JavaMail.root@jennyfur.pelican.org>
Message-ID: <EC993E87D960A541A66BF21D62AA42A6232C85C808@exch2k7.gilat.local>

Assuming that terrorists or any other embargoed country will try to * legally* obtain crypto software from Cisco or any other vendor is like assuming that you could catch ganstas when they go to the weapon's store to buy their piece...
As I said before, is much easier to download ANY IOS from BitTorrent than you can possibly imagine, and I guess also terrorists know this little programs

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tim Franklin
Sent: Thursday, September 24, 2009 12:57 PM
To: Gert Doering
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Download manager hell and latest Windows VPN Client?

> Well.  You sound very serious, but I'm *sure* that you're making fun
> of me.
> 
> (Of course, terrorists would never lie regarding the "I'm no
> terrorist!"
> statement).

I think it's like convicting Al Capone of tax evasion.  You don't have to prove they did anything naughty with the software, just that they didn't tell the truth on the form.  The US Immigration people have a similar point of view, with their "are YOU anti-American?" pre-arrival form.

Personally, I think it just provides a Dawinian leg-up for the Bad People by weeding out the truly stupid from their ranks who would tell the truth to any such question ;)

Regards,
Tim.


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************




 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************




From jared at puck.nether.net  Thu Sep 24 10:01:10 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 24 Sep 2009 10:01:10 -0400
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS	Software	Tunnels
	Vulnerability
In-Reply-To: <20090924072626.GG1508@greenie.muc.de>
References: <200909231215.tunnels@psirt.cisco.com>
	<20090923191720.GC1508@greenie.muc.de> <4ABA7FD0.2000905@cisco.com>
	<6069A203FD01884885C037F81DD750801722C5947A@wsc-mail-01.intra.nwresd.k12.or.us>
	<20090924072626.GG1508@greenie.muc.de>
Message-ID: <DD38CFC8-8BCA-4B6E-8443-7768C2EA7A9B@puck.nether.net>

(psirt alias removed)

On Sep 24, 2009, at 3:26 AM, Gert Doering wrote:

> Hi,
>
> On Wed, Sep 23, 2009 at 08:11:28PM -0700, Bill Blackford wrote:
>> Sorry to reply to my own post. Someone on the list contacted me
>> off-list to point out that this does *not* include the "12.2.S"  
>> release.
>
> Well, since there *is no* other IOS than 12.2 SR / 12.2 SX for the
> Cat 6.5 / 7.6 boxes, it would be somewhat difficult to move to 12.4  
> here...
>

	The "end" of 12.2 Mainline does not impact the subtree SR/SX software  
trains.  These continue to live-on for bugfixes.

>> I apologize to the group.
>
> I can certainly understand the confusion caused by the IOS train  
> splits...

It's hard to understand, Cisco is a product company with hundreds of  
solutions and software sets that are tied to a platform, which have  
lineage to some long-dead train. This is the culture that has been  
created to ship a solution when a customer demands instead of when  
some engineering criteria has been met.

The balance is certainly tipped in favor of cisco collecting $ vs  
providing a quality product, I've watched this play out many times.  
This doesn't mean that PSIRT and other teams are not trying to do the  
right thing, just that the pull of revenue is strong. PSIRT is one of  
the best teams at cisco since they have the power to do the right  
thing, so please don't shoot the messenger :)

- Jared

From brian at bluecoat93.org  Thu Sep 24 10:09:34 2009
From: brian at bluecoat93.org (Brian Landers)
Date: Thu, 24 Sep 2009 10:09:34 -0400
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <20090924073839.GI1508@greenie.muc.de>
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>
	<4F5D9C2A-1FB8-4FF2-A91C-213290CB018B@puck.nether.net>
	<20090924073839.GI1508@greenie.muc.de>
Message-ID: <689ea7e40909240709q55b6e908l6a6e73c2e2801a20@mail.gmail.com>

On Thu, Sep 24, 2009 at 3:38 AM, Gert Doering <gert at greenie.muc.de> wrote:

>
> I really can't understand what is so hard about FTP access.
>
> Fill in a web form once, claim "yes, I'm no terrorist!", and then the
> FTP servers put you into a "he's no terrorist, may download crypto
> software" group...
>
> This is really "Internet 0.9" knowledge.
>
>
Unfortunately, I doubt it's Cisco saying "we must stop terrorists from
downloading strong encryption" and more the DoJ (or really the Commerce
Department) saying "you must do X, Y, and Z when providing downloads of
products with crypto or we'll sue you into oblivion."

Same reason that e.g. Vandyke requires an eligibility declaration before
downloading SecureCRT.


-- 
Brian C Landers
http://www.packetslave.com/
CCIE #23115

From gsgranados at comcast.net  Thu Sep 24 11:47:28 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Thu, 24 Sep 2009 08:47:28 -0700
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>	<4F5D9C2A-1FB8-4FF2-A91C-213290CB018B@puck.nether.net><20090924073839.GI1508@greenie.muc.de>
	<4ABB3602.9030102@inex.ie>
Message-ID: <006601ca3d2e$5751d090$2208120a@am.thmulti.com>

Come on, you can't be serious!  Suppose your terrorist isn't an external 
terrorist but some wack job from Marin who happens to be a citizen already? 
Besides, I think Metro PCS and Go phone are more terrorist friendly, not 
encryption. Terrorism is all about pay as you go anonymous cell phone plans 
and home made explosives, not strong cryptography. Besides, all terrorists 
would be honest and check yes just like all cops are honest and never check 
no on the "have you used drugs" question when they actually smoked a fatty 
in high school!


----- Original Message ----- 
From: "Nick Hilliard" <nick at inex.ie>
To: "Gert Doering" <gert at greenie.muc.de>
Cc: <cisco-nsp at puck.nether.net>
Sent: Thursday, September 24, 2009 2:04 AM
Subject: Re: [c-nsp] Download manager hell and latest Windows VPN Client?


> On 24/09/2009 08:38, Gert Doering wrote:
>> Fill in a web form once, claim "yes, I'm no terrorist!", and then the
>> FTP servers put you into a "he's no terrorist, may download crypto
>> software" group...
>>
>> This is really "Internet 0.9" knowledge.
>
> Gert,
>
> You're ignoring the possibility that people change over time.  What if a 
> person was a regular joe soap on the day that they filled out this web 
> form, but had become a terrorist within a short period of time?  How would 
> your single form proposal cope with this, pray tell?  Filling in the 
> terrorism / nuclear arms shipment / bioweapons form each time is designed 
> precisely to deal with smart alecs who think that they can get around arms 
> embargoes like this.
>
> Nick
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From justin at justinshore.com  Thu Sep 24 11:51:00 2009
From: justin at justinshore.com (Justin Shore)
Date: Thu, 24 Sep 2009 10:51:00 -0500
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <Pine.LNX.4.64.0909231830010.32526@whammy.cluebyfour.org>
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>
	<Pine.LNX.4.64.0909231830010.32526@whammy.cluebyfour.org>
Message-ID: <4ABB9564.8080402@justinshore.com>

Justin M. Streiner wrote:
> My main argument against the download manager applet is that I hate 
> dealing with several layers of dependency hell with Java.  Does the 
> download manager work with the Java plugin in my web browser when that 
> plugin is based on different JRE versions?  Also, there seems to be this 
> movement by some vendors to replace simple processes (an HTTP or FTP 
> download) with something bulkier, like a Java applet, presumably because 
> it looks prettier.  Putting my business hat on for a second, I don't 
> understand the value proposition.

I've been in situations where I had to download an IOS image with the el 
cheapo browser in my data phone that does not have Java support, save it 
to the MicroSD card and then use a card reader to transfer that to my 
laptop so I could fix a critical network issue.  Java isn't a universal 
way of leveling the playing field.  It's the bastion of lazy programmers 
and buzzword-loving PHBs.

Justin



From gsgranados at comcast.net  Thu Sep 24 11:51:26 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Thu, 24 Sep 2009 08:51:26 -0700
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>	<Pine.LNX.4.64.0909231830010.32526@whammy.cluebyfour.org><Pine.LNX.4.64.0909231949450.31299@ryouko.imsb.nrc.ca>
	<4ABACB4D.5000009@rollernet.us>
Message-ID: <00b701ca3d2e$e4f98c30$2208120a@am.thmulti.com>

That's a great idea, I'm going to open a case everytime I need an image or 
every time some web interface is unaccessible!

----- Original Message ----- 
From: "Seth Mattinen" <sethm at rollernet.us>
To: <cisco-nsp at puck.nether.net>
Sent: Wednesday, September 23, 2009 6:28 PM
Subject: Re: [c-nsp] Download manager hell and latest Windows VPN Client?


> William F. Maton Sotomayor wrote:
>> On Wed, 23 Sep 2009, Justin M. Streiner wrote:
>>
>>>>   All that aside, does anyone have a non Cisco pointer or back way in
>>>> to Cisco's site that I can use to download the latest V5.X windows XP
>>>> VPN client?  Any pointers would be appreciated.
>> [snip]
>>> Echoing Scott's request, if there is an 'off the menu' way to still
>>> access software downloads the old way, I'm all for it.
>>
>> Accessibility issues aside (perfectly valid points as well), I too have
>> just today experienced JAVA 'Download Manager' hell.  I did voice my
>> disapproval through the form there and good a polite response back
>> pointing me to the usual JAVA version caveats.  I responded back
>> (equally politely) that I did test my browser's JAVA plugin and it
>> claimed I was compliant.  The JAVA applet still failed to load.
>>
>> I subsequently coaxed the JAVA console out of hiding and asked for the
>> log and traceback, enclosed that too.
>>
>> In the meantime, I asked my friendly neighbourhood SE about download
>> alternatives.  He suggested I should open a TAC case.  Oh dear. I wonder
>> how many of those are being opened by others as I type this....?
>>
>
> Stop downloading completely; everyone just open TAC cases from now on
> when you need an image. That might make it on someone's radar.
>
> ~Seth
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From peter at rathlev.dk  Thu Sep 24 11:56:41 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Thu, 24 Sep 2009 17:56:41 +0200
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <6B43981C32F8464CB24CEE209DA32BD3025A2B5C@kenya.tronet.as>
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>
	<4F5D9C2A-1FB8-4FF2-A91C-213290CB018B@puck.nether.net>
	<20090924073839.GI1508@greenie.muc.de> <4ABB3602.9030102@inex.ie>
	<20090924094417.GM1508@greenie.muc.de>
	<6B43981C32F8464CB24CEE209DA32BD3025A2B5C@kenya.tronet.as>
Message-ID: <1253807801.3522.6.camel@abehat.net.rm.dk>

On Thu, 2009-09-24 at 11:44 +0200, Gert Doering wrote:
> (Of course, terrorists would never lie regarding the "I'm no
> terrorist!" statement).

On Thu, 2009-09-24 at 12:41 +0200, Daniska, Tomas wrote:
> hey... then I suggest launching the ftp/http client with --evilbit=0
> option ;->

On a completely serious side note: The marketing people at Cisco have
completely overlooked this excellent opportunity to implement RFC 3514
compliance.

Why oh why have Cisco started behaving like the people we normally make
fun of. :-|

-- 
Peter



From justin at justinshore.com  Thu Sep 24 12:04:54 2009
From: justin at justinshore.com (Justin Shore)
Date: Thu, 24 Sep 2009 11:04:54 -0500
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <20090924073839.GI1508@greenie.muc.de>
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>	<4F5D9C2A-1FB8-4FF2-A91C-213290CB018B@puck.nether.net>
	<20090924073839.GI1508@greenie.muc.de>
Message-ID: <4ABB98A6.6060900@justinshore.com>

Gert Doering wrote:
> I really can't understand what is so hard about FTP access.
> 
> Fill in a web form once, claim "yes, I'm no terrorist!", and then the
> FTP servers put you into a "he's no terrorist, may download crypto 
> software" group...
> 
> This is really "Internet 0.9" knowledge.

Or if they are concerned about encrypted data paths they could use SFTP 
or FTPS (greatly prefer SFTP).

I've said it before and I'll say it again.  Forward-facing product pages 
can have all the marketing fluff to help sell the product.  Once we own 
the product we users and customers of Cisco use the support pages. 
There should be absolutely no marketing fluff on any of those pages, 
ever.  Technical supports resources should border on the verge of being 
called ugly.  Don't waste my time as a technical admin with your 
marketing fluff Flash and Shockwave animations.  Give me what I need so 
I can keep your product up and running and my management happy.  If they 
aren't happy we aren't buying any more of your product.  It's not rocket 
science.

Justin


From harbor235 at gmail.com  Thu Sep 24 12:15:33 2009
From: harbor235 at gmail.com (harbor235)
Date: Thu, 24 Sep 2009 12:15:33 -0400
Subject: [c-nsp] modular code for the 6500
Message-ID: <836bf1f90909240915l5ee5ba15g73f87f3bbcce53bc@mail.gmail.com>

Is anyone out there using 6500 modular code? Is it stable? I have a 6509
with 720-3B, I would like
to use the modualr code but also do not want instability, any
thoughts/experiences would be appreciated.

mike

From justin at justinshore.com  Thu Sep 24 12:18:34 2009
From: justin at justinshore.com (Justin Shore)
Date: Thu, 24 Sep 2009 11:18:34 -0500
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <689ea7e40909240709q55b6e908l6a6e73c2e2801a20@mail.gmail.com>
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>	<4F5D9C2A-1FB8-4FF2-A91C-213290CB018B@puck.nether.net>	<20090924073839.GI1508@greenie.muc.de>
	<689ea7e40909240709q55b6e908l6a6e73c2e2801a20@mail.gmail.com>
Message-ID: <4ABB9BDA.7000909@justinshore.com>

Brian Landers wrote:
> Same reason that e.g. Vandyke requires an eligibility declaration before
> downloading SecureCRT.

Yes, but even Vandyke now lets you answer the question once and no 
longer have to answer it again.  (Saying this as I'm downloading the 
SCRT 6.2.3 upgrade right now with my licensed user account...)

Justin

From MatlockK at exempla.org  Thu Sep 24 12:51:05 2009
From: MatlockK at exempla.org (Matlock, Kenneth L)
Date: Thu, 24 Sep 2009 10:51:05 -0600
Subject: [c-nsp] modular code for the 6500
In-Reply-To: <836bf1f90909240915l5ee5ba15g73f87f3bbcce53bc@mail.gmail.com>
References: <836bf1f90909240915l5ee5ba15g73f87f3bbcce53bc@mail.gmail.com>
Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7065D3ABE@LMC-MAIL2.exempla.org>

We were running 12.2(18)SXF6 for the better part of 2 years now on
multiple Sup720-3B's. (About 80 separate chassis).

I'd stay away from the SXF train, as we've recently finally tracked down
a nasty memory leak problem, and are actually moving away from Modular,
and reverting back to standard IOS. The bug we're seeing (CSCsr12976) is
triggered by a 'show run' command, with it not releasing some of it's
memory. After time the Kernel process winds up spiking the CPU, causing
intermittent throughput issues, as well as EIGRP/HSRP flapping. The fix
is to swap to the redundant supervisor. We have other chassis running
the exact same code release, but non-modular, without any sorts of
issues. 

Because of that, and the fact that from our side, we don't see any real
benefit of going modular over non-modular. We have never had to restart
a process, never had to patch a process (don't even remember any patches
ever coming out).

For us, it's not worth it so we're going back.

Ken Matlock
Network Analyst
Exempla Healthcare
(303) 467-4671
matlockk at exempla.org


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of harbor235
Sent: Thursday, September 24, 2009 10:16 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] modular code for the 6500

Is anyone out there using 6500 modular code? Is it stable? I have a 6509
with 720-3B, I would like
to use the modualr code but also do not want instability, any
thoughts/experiences would be appreciated.

mike
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From mksmith at adhost.com  Thu Sep 24 13:01:03 2009
From: mksmith at adhost.com (Michael K. Smith)
Date: Thu, 24 Sep 2009 10:01:03 -0700
Subject: [c-nsp] closing ports
In-Reply-To: <997578.94458.qm@web53709.mail.re2.yahoo.com>
Message-ID: <C6E0F3DF.B032B%mksmith@adhost.com>

Hello:


On 9/23/09 11:58 PM, "abs" <abhishake00 at yahoo.com> wrote:

> Hello all, 
> I am new to this so please excuse my ignorance.
> 
> I am running the following version of IOS: Cisco IOS Software, 2800 Software
> (C2800NM-ADVENTERPRISEK9-M), Version 12.4(11)T, RELEASE SOFTWARE (fc2)
> 
> I recently made some changes to the config at which point a port scan on the
> router is showing all ports to be open.? I only want 80, 8080, and 22 to be
> open.? I know this is something very basic but I cannot seem to figure it
> out.? Here is my partial config.? Please let me know if additional information
> is required.? Thank you in advance.
> 
> ==============================
> 
> ip nat inside source list 2 interface Cable-Modem0/0/0 overload
> ip nat inside source list 4 interface Cable-Modem0/0/0 overload
> ip nat inside source static tcp 192.168.2.210 8080 interface Cable-Modem0/0/0
> 8080
> ip nat inside source static tcp 192.168.2.208 22 interface Cable-Modem0/0/0 22
> ip nat inside source static tcp 192.168.2.208 80 interface Cable-Modem0/0/0 80
> 
> access-list 2 permit 192.168.2.0 0.0.0.255
> access-list 2 deny?? any
> access-list 4 permit 192.168.54.0 0.0.0.255
> access-list 4 deny?? any
> 
> ================ end config ================
> 
You will need to add an access-list for that traffic and apply it to the
appropriate interface.  First off, do you want 80/8080/22 allowed in from
the outside, or in from your cable modems, or both?  The answer to that
determines which interface(s) to apply the ACL to.

Access-list 100 permit tcp any any eq 80
Access-list 100 permit tcp any any eq 8080
Access-list 100 permit tcp any any eq 20
Access-list 100 deny ip any any

Interface <whichever you want>
Access-group 100 in

Regards,

Mike


From cisco at peakpeak.com  Thu Sep 24 14:10:06 2009
From: cisco at peakpeak.com (CJ)
Date: Thu, 24 Sep 2009 12:10:06 -0600
Subject: [c-nsp] Pile on the 6509 noob
In-Reply-To: <mailman.3.1253808001.21321.cisco-nsp@puck.nether.net>
Message-ID: <C6E1121E.4FD6%cisco@peakpeak.com>

I am a new 6509 manager (caregiver?) and so far having an OK time.  I have
some little problems to solve.

One of them is a FlexWAN card WS-X6182-2PA. It gives an error when inserted
about memory. I assume it doesn't have enough.

00:03:33: %FIB-3-FIBDISABLE: Fatal error, slot/cpu 6/0: no memory
00:03:33: %FIB-3-FIBDISABLE: Fatal error, slot/cpu 6/1: no memory

There is definitely memory on the card (physically plugged in) so what does
this mean?

Finally, if I solved this issue, I'm wondering about the relative wisdom of
using the FlexWAN card.  I want to put a PA-2DS3 in it and also a PA-MC-T3.
Is this an enlightened practice?

Thanks,
CJ



From justin at justinshore.com  Thu Sep 24 16:26:29 2009
From: justin at justinshore.com (Justin Shore)
Date: Thu, 24 Sep 2009 15:26:29 -0500
Subject: [c-nsp] modular code for the 6500
In-Reply-To: <836bf1f90909240915l5ee5ba15g73f87f3bbcce53bc@mail.gmail.com>
References: <836bf1f90909240915l5ee5ba15g73f87f3bbcce53bc@mail.gmail.com>
Message-ID: <4ABBD5F5.4070705@justinshore.com>

harbor235 wrote:
> Is anyone out there using 6500 modular code? Is it stable? I have a 6509
> with 720-3B, I would like
> to use the modualr code but also do not want instability, any
> thoughts/experiences would be appreciated.

If you go the modular route make sure you use the Feature Navigator to 
compare modular and non-modular release to find the feature differences. 
  One would think that they'd be the same or very close.  They are not. 
  I don't know why that happened either but there's probably a reason. 
Just make sure you look before you leap.

http://www.cisco.com/go/fn/

Justin



From gsgranados at comcast.net  Thu Sep 24 16:50:30 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Thu, 24 Sep 2009 13:50:30 -0700
Subject: [c-nsp] ASA5520 which image should I use?
Message-ID: <00d401ca3d58$ab0e54e0$2208120a@am.thmulti.com>

Hi, I'm running a pair of ASA5520 devices as VPN concentrators.  Presently 
there is a software image installed that seems very old and was actually 
shipped with the devices before I arrived on the scene.  I'm experiencing 
some issues with bringing up L2L tunnels and figured that a firmware update 
was in order.  What version are folks using successfully?  I was thinking of 
going with the 8X code but not sure which one to choose.  The features I'm 
using are very basic and include simple client access and LAN to LAN access, 
I'm not using the anyconnect or web VPN features at this point.  Which image 
do you think would fit the bill the best?  Any pointers would be 
appreciated.

Thank you
Scott


From jsahala at gmail.com  Thu Sep 24 16:53:22 2009
From: jsahala at gmail.com (joshua sahala)
Date: Thu, 24 Sep 2009 14:53:22 -0600
Subject: [c-nsp] OSPF to ISIS migartion
In-Reply-To: <8bb137f40909230050vce3c824mc31113a20bfde129@mail.gmail.com>
References: <8bb137f40909230050vce3c824mc31113a20bfde129@mail.gmail.com>
Message-ID: <4b8f66d70909241353q5bddc874i6678bf37d706ba9d@mail.gmail.com>

On Wed, Sep 23, 2009 at 1:50 AM, jack daniels <jckdaniels12 at gmail.com> wrote:
[cut]
> WHAT CONSIDERATIONS TO KEEP IN MIND BEFORE MIGRATION.


as others have shared, vijay's presentation and methodology were spot on:
  - have ALL of your configurations pre-written/staged/tested
  - have a well organised plan of what order you will touch
everything that is being converted,
      or clear boundaries if you have to do it in stages so that
nothing is missed
  - execute the plan
  - verify the config on every device that was supposed to be touched

i've gone through the dance two times now (and preparing for a third
^_^ ) and haven't had any issues beyond lack of vendor support (cisco)
for the protocol.

wrt to the poster who said "just run ospfv3", i would disagree:  you
are adding significant complexity by running yet another routing
protocol (yarp?!?!) across the infrastructure, as well as adding
operational overhead.  in one of the two cases i've converted, it was
largely because we didn't want to run two distinct igps, and is-is is
a single and arguably simpler protocol  (<insert rant about the
simplicity of tlv versus lsa and size of code-base>)

my $0.02usd
/joshua
(apologies if this is a duplicate post)
-- 
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
        - Douglas Adams -

From rwest at zyedge.com  Thu Sep 24 16:59:18 2009
From: rwest at zyedge.com (Ryan West)
Date: Thu, 24 Sep 2009 16:59:18 -0400
Subject: [c-nsp] ASA5520 which image should I use?
In-Reply-To: <00d401ca3d58$ab0e54e0$2208120a@am.thmulti.com>
References: <00d401ca3d58$ab0e54e0$2208120a@am.thmulti.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124C180EF4F@zy-ex1.zyedge.local>

Scott,

If you don't think you'll be using 8.x features anytime, I have a lot of luck with 7.2(4)33.  Avoid the middle interim releases as there are a couple of nasty ISAKMP bugs.  Getting to those downloads can be a bit of a challenge now, but this link still works, just go to the Interim Releases.

http://www.cisco.com/cgi-bin/tablebuild.pl/asa

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Thursday, September 24, 2009 4:51 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ASA5520 which image should I use?

Hi, I'm running a pair of ASA5520 devices as VPN concentrators.  Presently 
there is a software image installed that seems very old and was actually 
shipped with the devices before I arrived on the scene.  I'm experiencing 
some issues with bringing up L2L tunnels and figured that a firmware update 
was in order.  What version are folks using successfully?  I was thinking of 
going with the 8X code but not sure which one to choose.  The features I'm 
using are very basic and include simple client access and LAN to LAN access, 
I'm not using the anyconnect or web VPN features at this point.  Which image 
do you think would fit the bill the best?  Any pointers would be 
appreciated.

Thank you
Scott

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From A.L.M.Buxey at lboro.ac.uk  Thu Sep 24 17:57:19 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Thu, 24 Sep 2009 22:57:19 +0100
Subject: [c-nsp] OSPF to ISIS migartion
In-Reply-To: <4b8f66d70909241353q5bddc874i6678bf37d706ba9d@mail.gmail.com>
References: <8bb137f40909230050vce3c824mc31113a20bfde129@mail.gmail.com>
	<4b8f66d70909241353q5bddc874i6678bf37d706ba9d@mail.gmail.com>
Message-ID: <20090924215719.GA22353@lboro.ac.uk>

Hi,

> as others have shared, vijay's presentation and methodology were spot on:
>   - have ALL of your configurations pre-written/staged/tested
>   - have a well organised plan of what order you will touch
> everything that is being converted,
>       or clear boundaries if you have to do it in stages so that
> nothing is missed
>   - execute the plan
>   - verify the config on every device that was supposed to be touched

I'd agree. plan in advance. prepare the config. 
enable and configure the ISIS, ensure that everything is using it,
lower the OSPF priority so ISIS takes over. check everything is
all okay. turn OSPF off. done.

alan

From peter at rathlev.dk  Thu Sep 24 18:11:07 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Fri, 25 Sep 2009 00:11:07 +0200
Subject: [c-nsp] ASA5520 which image should I use?
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E140124C180EF4F@zy-ex1.zyedge.local>
References: <00d401ca3d58$ab0e54e0$2208120a@am.thmulti.com>
	<6E21B2BDEF6E714EA0B5BA8D5D0E140124C180EF4F@zy-ex1.zyedge.local>
Message-ID: <1253830267.6945.11.camel@abehat.net.rm.dk>

On Thu, 2009-09-24 at 16:59 -0400, Ryan West wrote:
> If you don't think you'll be using 8.x features anytime, I have a lot
> of luck with 7.2(4)33.

Agreed, 7.2(4) rebuilds have served us in a stable way for a long time.

> Avoid the middle interim releases as there are a couple of nasty
> ISAKMP bugs.  Getting to those downloads can be a bit of a challenge
> now, but this link still works, just go to the Interim Releases.
> 
> http://www.cisco.com/cgi-bin/tablebuild.pl/asa

As a side note: I can't seem to find the interim releases via the
splendid new Download Area. Considering the number and importance of bug
fixes in the interim releases it seems a little odd not to include them.

The URL has that look you know, the look that means someone at Ciscos
webteam is bound to replace it with something flashy/java-y. :-)

-- 
Peter



From amsoares at netcabo.pt  Thu Sep 24 19:23:23 2009
From: amsoares at netcabo.pt (Antonio Soares)
Date: Fri, 25 Sep 2009 00:23:23 +0100
Subject: [c-nsp] ASA5520 which image should I use?
In-Reply-To: <00d401ca3d58$ab0e54e0$2208120a@am.thmulti.com>
References: <00d401ca3d58$ab0e54e0$2208120a@am.thmulti.com>
Message-ID: <216854CA1A7F40098A49F3C959854852@int.convex.pt>

Stay away from 8.2. We are experiencing crashes since July (TAC case involved). Tomorrow we will install 8.2.1-10 to see if finally
we get rid of this.


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: quinta-feira, 24 de Setembro de 2009 21:51
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ASA5520 which image should I use?

Hi, I'm running a pair of ASA5520 devices as VPN concentrators.  Presently there is a software image installed that seems very old
and was actually shipped with the devices before I arrived on the scene.  I'm experiencing some issues with bringing up L2L tunnels
and figured that a firmware update was in order.  What version are folks using successfully?  I was thinking of going with the 8X
code but not sure which one to choose.  The features I'm using are very basic and include simple client access and LAN to LAN
access, I'm not using the anyconnect or web VPN features at this point.  Which image do you think would fit the bill the best?  Any
pointers would be appreciated.

Thank you
Scott

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



From gsgranados at comcast.net  Thu Sep 24 19:34:27 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Thu, 24 Sep 2009 16:34:27 -0700
Subject: [c-nsp] ASA5520 which image should I use?
References: <00d401ca3d58$ab0e54e0$2208120a@am.thmulti.com>
	<216854CA1A7F40098A49F3C959854852@int.convex.pt>
Message-ID: <018e01ca3d6f$9416b220$2208120a@am.thmulti.com>

Hi, thanks for the pointers.

I think I'm going to give 7.2.4-33 a shot and stay clear of the 8X.

Thank you
Scott

----- Original Message ----- 
From: "Antonio Soares" <amsoares at netcabo.pt>
To: "'Scott Granados'" <gsgranados at comcast.net>; <cisco-nsp at puck.nether.net>
Sent: Thursday, September 24, 2009 4:23 PM
Subject: RE: [c-nsp] ASA5520 which image should I use?


> Stay away from 8.2. We are experiencing crashes since July (TAC case 
> involved). Tomorrow we will install 8.2.1-10 to see if finally
> we get rid of this.
>
>
> Regards,
>
> Antonio Soares, CCIE #18473 (R&S)
> amsoares at netcabo.pt
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
> Sent: quinta-feira, 24 de Setembro de 2009 21:51
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] ASA5520 which image should I use?
>
> Hi, I'm running a pair of ASA5520 devices as VPN concentrators.  Presently 
> there is a software image installed that seems very old
> and was actually shipped with the devices before I arrived on the scene. 
> I'm experiencing some issues with bringing up L2L tunnels
> and figured that a firmware update was in order.  What version are folks 
> using successfully?  I was thinking of going with the 8X
> code but not sure which one to choose.  The features I'm using are very 
> basic and include simple client access and LAN to LAN
> access, I'm not using the anyconnect or web VPN features at this point. 
> Which image do you think would fit the bill the best?  Any
> pointers would be appreciated.
>
> Thank you
> Scott
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> 


From amsoares at netcabo.pt  Thu Sep 24 19:37:09 2009
From: amsoares at netcabo.pt (Antonio Soares)
Date: Fri, 25 Sep 2009 00:37:09 +0100
Subject: [c-nsp] ASA5520 which image should I use?
In-Reply-To: <1253830267.6945.11.camel@abehat.net.rm.dk>
References: <00d401ca3d58$ab0e54e0$2208120a@am.thmulti.com><6E21B2BDEF6E714EA0B5BA8D5D0E140124C180EF4F@zy-ex1.zyedge.local>
	<1253830267.6945.11.camel@abehat.net.rm.dk>
Message-ID: <21A2FDC890F0422E8AA83C2D500B235F@int.convex.pt>

It still works:

http://www.cisco.com/cgi-bin/tablebuild.pl/asa

Or when you are on the page with the "Download Now" button, click the "Previous ASA Releases" link. 


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Rathlev
Sent: quinta-feira, 24 de Setembro de 2009 23:11
To: Scott Granados; Ryan West
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 which image should I use?

On Thu, 2009-09-24 at 16:59 -0400, Ryan West wrote:
> If you don't think you'll be using 8.x features anytime, I have a lot 
> of luck with 7.2(4)33.

Agreed, 7.2(4) rebuilds have served us in a stable way for a long time.

> Avoid the middle interim releases as there are a couple of nasty 
> ISAKMP bugs.  Getting to those downloads can be a bit of a challenge 
> now, but this link still works, just go to the Interim Releases.
> 
> http://www.cisco.com/cgi-bin/tablebuild.pl/asa

As a side note: I can't seem to find the interim releases via the splendid new Download Area. Considering the number and importance
of bug fixes in the interim releases it seems a little odd not to include them.

The URL has that look you know, the look that means someone at Ciscos webteam is bound to replace it with something flashy/java-y.
:-)

--
Peter


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



From philxor at gmail.com  Thu Sep 24 22:13:06 2009
From: philxor at gmail.com (Phil Bedard)
Date: Thu, 24 Sep 2009 22:13:06 -0400
Subject: [c-nsp] Inter-AS L2VPN redundancy, option B (Ruzhanskaya Olga)
In-Reply-To: <E1MqMw9-0005oY-00.frosya84-mail-ru@f112.mail.ru>
References: <E1MqMw9-0005oY-00.frosya84-mail-ru@f112.mail.ru>
Message-ID: <6B483C0E-AB2D-46F7-9204-FD9596BBDDAD@gmail.com>

If you are using BGP Signaling for L2VPN (Kompella style) Option B is  
an option but not for Martini-style LDP signaled pseudowires.  You  
would still need L2VPN inter-as support for option B, which I'm not  
sure Cisco even supports.

You could use option C with targeted LDP sessions between the remote  
ASBRs to exchange VC labels and then use MBGP between AS2/AS1 for  
transport between ASBR2/ASBR3.   The transport LSP can easily be made  
redundant.



Phil


On Sep 23, 2009, at 4:10 AM, ????? ????????? wrote:

> Hello List!
>
> My company is working on building Inter-AS VPN connection with other  
> provider (both using MPLS).
> After researching on different option we've decided to use Option B  
> (single-hop MP-EBGP).
> The only way to build l2vpn for option B is to use point-to-point  
> VFI on ASBRs:
> http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_l2vpn_pseudo_swit_ps6922_TSD_Products_Configuration_Guide_Chapter.html#wp1059907
>
> We've found information how to build redundant schemes for L3VPN,  
> but redundancy for l2vpn is a problem..
> If we have the following topology (2 ASBRs in one AS with  
> connections to 1 ASBR in other AS):
> ASBR2(AS2)
>   |
> ASBR1(AS1)
>   |
> ASBR3(AS2)
> is it possible to build a redundant l2vpn?
>
> As I understand, to use L2VPN Pseudowire Redundancy, we need  
> directed control protocol between the peer routers, and there is no  
> such protocol (LDP, for example) in nature of option B.
> But maybe someone have already decided such question?
>
> I will be very glad for any suggestions/documents(it is so little  
> information about inter-as l2!)
>
> Best regards,
> Olga
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From tvarriale at comcast.net  Thu Sep 24 23:05:43 2009
From: tvarriale at comcast.net (Tony Varriale)
Date: Thu, 24 Sep 2009 22:05:43 -0500
Subject: [c-nsp] modular code for the 6500
References: <836bf1f90909240915l5ee5ba15g73f87f3bbcce53bc@mail.gmail.com>
Message-ID: <FDFA03A8DE9E491A9073052245F6C7A3@flamdt01>

I've attempted it with a couple of customers and it always ended up being a 
train wreck.

I'm not even recommending it until it gets much further along and gets some 
serious field experience.

tv
----- Original Message ----- 
From: "harbor235" <harbor235 at gmail.com>
To: <cisco-nsp at puck.nether.net>
Sent: Thursday, September 24, 2009 11:15 AM
Subject: [c-nsp] modular code for the 6500


> Is anyone out there using 6500 modular code? Is it stable? I have a 6509
> with 720-3B, I would like
> to use the modualr code but also do not want instability, any
> thoughts/experiences would be appreciated.
>
> mike
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From tvarriale at comcast.net  Fri Sep 25 00:58:27 2009
From: tvarriale at comcast.net (Tony Varriale)
Date: Thu, 24 Sep 2009 23:58:27 -0500
Subject: [c-nsp] ASA5520 which image should I use?
References: <00d401ca3d58$ab0e54e0$2208120a@am.thmulti.com>
	<216854CA1A7F40098A49F3C959854852@int.convex.pt>
Message-ID: <994D611344A246CFBF199BFE46F013F0@flamdt01>

In?
----- Original Message ----- 
From: "Antonio Soares" <amsoares at netcabo.pt>
To: "'Scott Granados'" <gsgranados at comcast.net>; <cisco-nsp at puck.nether.net>
Sent: Thursday, September 24, 2009 6:23 PM
Subject: Re: [c-nsp] ASA5520 which image should I use?


> Stay away from 8.2. We are experiencing crashes since July (TAC case 
> involved). Tomorrow we will install 8.2.1-10 to see if finally
> we get rid of this.
>
>
> Regards,
>
> Antonio Soares, CCIE #18473 (R&S)
> amsoares at netcabo.pt
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
> Sent: quinta-feira, 24 de Setembro de 2009 21:51
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] ASA5520 which image should I use?
>
> Hi, I'm running a pair of ASA5520 devices as VPN concentrators.  Presently 
> there is a software image installed that seems very old
> and was actually shipped with the devices before I arrived on the scene. 
> I'm experiencing some issues with bringing up L2L tunnels
> and figured that a firmware update was in order.  What version are folks 
> using successfully?  I was thinking of going with the 8X
> code but not sure which one to choose.  The features I'm using are very 
> basic and include simple client access and LAN to LAN
> access, I'm not using the anyconnect or web VPN features at this point. 
> Which image do you think would fit the bill the best?  Any
> pointers would be appreciated.
>
> Thank you
> Scott
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From dwcarder at wisc.edu  Fri Sep 25 01:03:45 2009
From: dwcarder at wisc.edu (Dale W. Carder)
Date: Fri, 25 Sep 2009 00:03:45 -0500
Subject: [c-nsp] modular code for the 6500
In-Reply-To: <FDFA03A8DE9E491A9073052245F6C7A3@flamdt01>
References: <836bf1f90909240915l5ee5ba15g73f87f3bbcce53bc@mail.gmail.com>
	<FDFA03A8DE9E491A9073052245F6C7A3@flamdt01>
Message-ID: <C7AF26EB-3A36-4BB8-997F-BA598CE829A3@wisc.edu>


My theory has been that we'll run modular only when we will
have to, i.e. when monolithic is no longer a reasonable
option.

I figure that day will be when once of two forces collide:
a) the last important big customer holding out finally gives
modular their blessing and no longer demands monolithic builds.
b) new hardware with only modular code.  probably will require
step 'a' above.

Having gotten to play with the modularity features on a demo
CRS-1 in 2005, "modular IOS" is, well, <yawn>.

Dale

On Sep 24, 2009, at 10:05 PM, Tony Varriale wrote:

> I've attempted it with a couple of customers and it always ended up  
> being a train wreck.
>
> I'm not even recommending it until it gets much further along and  
> gets some serious field experience.
>
> tv
> ----- Original Message ----- From: "harbor235" <harbor235 at gmail.com>
> To: <cisco-nsp at puck.nether.net>
> Sent: Thursday, September 24, 2009 11:15 AM
> Subject: [c-nsp] modular code for the 6500
>
>
>> Is anyone out there using 6500 modular code? Is it stable? I have a  
>> 6509
>> with 720-3B, I would like
>> to use the modualr code but also do not want instability, any
>> thoughts/experiences would be appreciated.
>>
>> mike
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From frnkblk at iname.com  Fri Sep 25 00:23:00 2009
From: frnkblk at iname.com (Frank Bulk)
Date: Thu, 24 Sep 2009 23:23:00 -0500
Subject: [c-nsp] Configuration challenge with NAT
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACbmHpyXb6HRIAUJ2BEOwQuAQAAAAA=@iname.com>

I have a customer who posed a NAT question that I didn't feel I optimally
answered.

They have a Cisco router (model is not relevant) with one serial WAN
interface (T-1) and one Ethernet interface.  On the WAN side they have a /29
network to the ISP.  They also received a /29 of public IPs for internal
use.  They have several servers and devices that they want to assign these
public IP addresses to.  They don't have a separate firewall/NAT device, but
want to give internet access to several dozen company PCs via NAT.

Is there a way to use VLANs on the Ethernet interface so that some of the
public IPs for internal use can be used by the customer's servers AND the
customer's PCs can NAT against either one of the remaining public IPs for
internal use or one of the remaining public WAN IPs?

i.e.:
Server 1 with public IP f.g.h.1--\
Server 2 with public IP f.g.h.2---\  VLAN 1 
Server 3 with public IP f.g.h.3----|
					     ==== customer router
a.b.c.e---T1---a.b.c.d ISP router----Internet
                                   |
           PCs with private IPs---/  VLAN 2 

Regards,

Frank


From peter.hicks at poggs.co.uk  Fri Sep 25 02:52:05 2009
From: peter.hicks at poggs.co.uk (Peter Hicks)
Date: Fri, 25 Sep 2009 07:52:05 +0100
Subject: [c-nsp] Download manager hell and latest Windows VPN Client?
In-Reply-To: <4ABB9564.8080402@justinshore.com>
References: <038b01ca3c9a$4c8f4b90$2208120a@am.thmulti.com>	<Pine.LNX.4.64.0909231830010.32526@whammy.cluebyfour.org>
	<4ABB9564.8080402@justinshore.com>
Message-ID: <4ABC6895.5020503@poggs.co.uk>

Justin Shore wrote:

> I've been in situations where I had to download an IOS image with the el 
> cheapo browser in my data phone that does not have Java support, save it 
> to the MicroSD card and then use a card reader to transfer that to my 
> laptop so I could fix a critical network issue.  Java isn't a universal 
> way of leveling the playing field.  It's the bastion of lazy programmers 
> and buzzword-loving PHBs.

I prepared a set of links on an internal Wiki page to IOS images for a 
new datacentre I am planning.  The idea was that one of my team can 
download the images when they are ready.  Guess what doesn't work at all 
now?  That's right - I have to go back and redo the work, and the team 
member needs to go hunt down the right IOS.

Javascript is one thing, but full-blown Java is wholly unnecessary.  I 
notice Dell.com have a 'download manager' now - but why?  What is wrong 
with a simple HTTP download without all this extra faff?


Peter


From andy.saykao at staff.netspace.net.au  Fri Sep 25 02:55:48 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Fri, 25 Sep 2009 16:55:48 +1000
Subject: [c-nsp] Which IP's belong to AS1234?
Message-ID: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>

This might be a silly question but is there a tool somewhere that will
give me a list of IP's that are owned by a particular AS.
 
As an example, I might want to know which IP blocks belong to AS1234?
 
Thanks.
 
Andy

This email and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed. 
Please notify the sender immediately by email if you have received this 
email by mistake and delete this email from your system. 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 organisation. 
Finally, the recipient should check this email and any attachments for 
the presence of viruses. The organisation accepts no liability for any 
damage caused by any virus transmitted by this email.


From mail4hh at pobox.com  Fri Sep 25 03:29:17 2009
From: mail4hh at pobox.com (Hector Herrera)
Date: Fri, 25 Sep 2009 00:29:17 -0700
Subject: [c-nsp] Which IP's belong to AS1234?
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <c7ef7cf70909250029m68992cb8h2086713b5cceba9@mail.gmail.com>

On Thu, Sep 24, 2009 at 11:55 PM, Andy Saykao
<andy.saykao at staff.netspace.net.au> wrote:
> This might be a silly question but is there a tool somewhere that will
> give me a list of IP's that are owned by a particular AS.
>
> As an example, I might want to know which IP blocks belong to AS1234?
>
> Thanks.
>
> Andy

Have you tried robtex?

http://www.robtex.com/as/as1234.html#bgp

Hector

From fweimer at bfk.de  Fri Sep 25 03:13:49 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Fri, 25 Sep 2009 07:13:49 +0000
Subject: [c-nsp] Which IP's belong to AS1234?
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>
	(Andy Saykao's message of "Fri\, 25 Sep 2009 16\:55\:48 +1000")
References: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <82r5tvjy36.fsf@mid.bfk.de>

* Andy Saykao:

> This might be a silly question but is there a tool somewhere that will
> give me a list of IP's that are owned by a particular AS.
>  
> As an example, I might want to know which IP blocks belong to AS1234?

Run this:

  show ip bgp regexp _1234$

on a router in the DFZ.  (I get a single prefix, 193.110.32.0/21,
right now.)

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

From andy.saykao at staff.netspace.net.au  Fri Sep 25 04:12:22 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Fri, 25 Sep 2009 18:12:22 +1000
Subject: [c-nsp] Which IP's belong to AS1234?
References: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>
	<4ABC718E.90908@thingy.com>
Message-ID: <56F211C5E3F24F47B103EA1B253822BE044AAC99@vic-cr-ex1.staff.netspace.net.au>

Thanks for the reply guys.

What I'm trying to achieve is to monitor the bandwidth utilization on
our Internet link. So for example we want to know how much bandwidth is
being utilized by our customers so we can say "ah huh out of our 100M
internet link, 90M of traffic is from youtube.com, so let's ask Google
if they want to peer with us". 

The device we are using refers to the Internet as the external network.
The device does not keep records of IP address information from the
external network, but we can specify classes under the external network.
So I could create a class called YouTube and associate the IPs 1.2.3.4
to 5.6.7.8 to this class and place it under the external network. The
device is then able to report that the YouTube class consumed X amount
of bandwidth on the external network interface. This is probably not the
best way to go about it, but that's the limitation of the device. 

This is why I needed to know what IP blocks belong to AS1234, so I could
find out how much traffic was actually coming from AS1234 on our
Internet link.

Cheers.

Andy

This email and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed. 
Please notify the sender immediately by email if you have received this 
email by mistake and delete this email from your system. 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 organisation. 
Finally, the recipient should check this email and any attachments for 
the presence of viruses. The organisation accepts no liability for any 
damage caused by any virus transmitted by this email.


From gert at greenie.muc.de  Fri Sep 25 04:33:20 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 25 Sep 2009 10:33:20 +0200
Subject: [c-nsp] Which IP's belong to AS1234?
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <20090925083320.GQ1508@greenie.muc.de>

Hi,

On Fri, Sep 25, 2009 at 04:55:48PM +1000, Andy Saykao wrote:
> This might be a silly question but is there a tool somewhere that will
> give me a list of IP's that are owned by a particular AS.
>  
> As an example, I might want to know which IP blocks belong to AS1234?

What exactly do you mean with "belong"?

Besides the fact that IP addresses are not property, even so, different
ways to look at that question will give different answers:

 - provided by a registry (RIPE, ARIN, etc.) to the company also holding
   AS1234 (and maybe other ASes)

 - announced by AS1234 (but that could as well be customer networks)

The first question is fairly difficult to answer.  The second can be 
answered by checking the BGP tables, e.g. on route-views.oregon-ix.net

$ telnet route-views.oregon-ix.net
...
route-views.oregon-ix.net>sh ip b reg _1234$
...
   Network          Next Hop            Metric LocPrf Weight Path
*  193.110.32.0/21  194.85.4.55                            0 3277 3216 6667 1234 1234 1234 1234 i


gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090925/b7828d57/attachment.bin>

From howie at thingy.com  Fri Sep 25 03:30:22 2009
From: howie at thingy.com (Howard Jones)
Date: Fri, 25 Sep 2009 08:30:22 +0100
Subject: [c-nsp] Which IP's belong to AS1234?
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <4ABC718E.90908@thingy.com>

Andy Saykao wrote:
> This might be a silly question but is there a tool somewhere that will
> give me a list of IP's that are owned by a particular AS.
>  
> As an example, I might want to know which IP blocks belong to AS1234?
>  
The RIPE IRR does this for europe at least, and I believe RIPE and ARIN 
collaborate on a US-centric equivalent. Those are based on ISPs keeping 
them up to date.

Or Robtex, or Fixed Orbit. Basically google for AS1234 and you'll find a 
few sites that collate peering and IP information from BGP collectors.

From ronan at iol.ie  Fri Sep 25 04:39:28 2009
From: ronan at iol.ie (Ronan Mullally)
Date: Fri, 25 Sep 2009 09:39:28 +0100 (IST)
Subject: [c-nsp] Which IP's belong to AS1234?
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AAC99@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>
	<4ABC718E.90908@thingy.com>
	<56F211C5E3F24F47B103EA1B253822BE044AAC99@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <alpine.DEB.2.00.0909250933480.14282@luggage>

Hi Andy,

On Fri, 25 Sep 2009, Andy Saykao wrote:

> This is why I needed to know what IP blocks belong to AS1234, so I could
> find out how much traffic was actually coming from AS1234 on our
> Internet link.

Some (possibly all?) Whois servers can provide you with this information
with:

 whois -h whois.ripe.net -i origin AS1234

 % Information related to '194.110.40.0/23AS1234'

 route:        194.110.40.0/23
 descr:        Imatran Voima Corporation
 descr:        EUnet-FI aggregate
 origin:       AS1234
 mnt-by:       AS790-MNT
 source:       RIPE # Filtered

 % Information related to '194.110.44.0/23AS1234'

 route:        194.110.44.0/23
 descr:        Carelcomp Power
 descr:        EUnet-FI aggregate
 origin:       AS1234
 mnt-by:       AS790-MNT
 source:       RIPE # Filtered

 % Information related to '193.110.32.0/21AS1234'

 route:        193.110.32.0/21
 descr:        Fortum
 origin:       AS1234
 mnt-by:       TE-ENERGY-NOC
 source:       RIPE # Filtered

(an inverse query looking for objects with an origin of AS1234).

I don't know how definitive it is - I've queried several large AS and got
nothing back.  It may be this functionality is only available in the RIPE
whois server.  There's also no guarantee the results are going to be
current or accurate.


-Ronan

From snatale at us.ntt.net  Fri Sep 25 04:22:52 2009
From: snatale at us.ntt.net (Steve Natale)
Date: Fri, 25 Sep 2009 08:22:52 +0000
Subject: [c-nsp] Which IP's belong to AS1234?
In-Reply-To: <c7ef7cf70909250029m68992cb8h2086713b5cceba9@mail.gmail.com>
References: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>
	<c7ef7cf70909250029m68992cb8h2086713b5cceba9@mail.gmail.com>
Message-ID: <20090925082252.GA12011@destroyer.troyspaws.com>

On Fri, Sep 25, 2009 at 12:29:17AM -0700, Hector Herrera wrote:
> On Thu, Sep 24, 2009 at 11:55 PM, Andy Saykao
> <andy.saykao at staff.netspace.net.au> wrote:
> > This might be a silly question but is there a tool somewhere that will
> > give me a list of IP's that are owned by a particular AS.
> >
> > As an example, I might want to know which IP blocks belong to AS1234?
> >
> > Thanks.
> >
> > Andy
> 
> Have you tried robtex?
> 
> http://www.robtex.com/as/as1234.html#bgp
> 
> Hector

You can also query a RR directly.  This method may be helpful 
if you need to do something else with the data.  

whois -h whois.radb.net \!gas1234
A48
194.110.40.0/23 194.110.44.0/23 193.110.32.0/21
C

Steve Natale
IP Engineer
snatale at us.ntt.net
NTT Communications Global IP Network

This email message is intended for the use of the person to whom it has been sent, and may
contain information that is confidential or legally protected. If you are not the intended
recipient or have received this message in error, you are not authorized to copy,
distribute, or otherwise use this message or its attachments. Please notify the sender
immediately by return e-mail and permanently delete this message and any attachments. NTT
America makes no warranty that this email is error or virus free. Thank you.

From Ian.Mackinnon at lumison.net  Fri Sep 25 04:23:31 2009
From: Ian.Mackinnon at lumison.net (Ian MacKinnon)
Date: Fri, 25 Sep 2009 09:23:31 +0100
Subject: [c-nsp] Which IP's belong to AS1234?
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AAC99@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>
	<4ABC718E.90908@thingy.com>
	<56F211C5E3F24F47B103EA1B253822BE044AAC99@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <B5F945E48C137C49A98BC86DD35939C01570664204@nbg01-exch-01.entlstaff.domain.lumison.net>

Hi Andy,

Does your device support netflow? That is the best answer for this sort of question.

If it does not, can you mirror the traffic to say a server and run ntop on that?

Ian

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Andy Saykao
Sent: 25 September 2009 09:12
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Which IP's belong to AS1234?

Thanks for the reply guys.

What I'm trying to achieve is to monitor the bandwidth utilization on
our Internet link. So for example we want to know how much bandwidth is
being utilized by our customers so we can say "ah huh out of our 100M
internet link, 90M of traffic is from youtube.com, so let's ask Google
if they want to peer with us".

The device we are using refers to the Internet as the external network.
The device does not keep records of IP address information from the
external network, but we can specify classes under the external network.
So I could create a class called YouTube and associate the IPs 1.2.3.4
to 5.6.7.8 to this class and place it under the external network. The
device is then able to report that the YouTube class consumed X amount
of bandwidth on the external network interface. This is probably not the
best way to go about it, but that's the limitation of the device.

This is why I needed to know what IP blocks belong to AS1234, so I could
find out how much traffic was actually coming from AS1234 on our
Internet link.

Cheers.

Andy

This email and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed.
Please notify the sender immediately by email if you have received this
email by mistake and delete this email from your system. 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 organisation.
Finally, the recipient should check this email and any attachments for
the presence of viruses. The organisation accepts no liability for any
damage caused by any virus transmitted by this email.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.112/2387 - Release Date: 09/24/09 05:52:00

--

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender. Any
offers or quotation of service are subject to formal specification.
Errors and omissions excepted.  Please note that any views or opinions
presented in this email are solely those of the author and do not
necessarily represent those of Lumison.
Finally, the recipient should check this email and any attachments for the
presence of viruses.  Lumison accept no liability for any
damage caused by any virus transmitted by this email.

From andy.petrenko at gmail.com  Fri Sep 25 05:23:06 2009
From: andy.petrenko at gmail.com (Andrey 'sshd' Petrenko)
Date: Fri, 25 Sep 2009 12:23:06 +0300
Subject: [c-nsp] Which IP's belong to AS1234?
In-Reply-To: <alpine.DEB.2.00.0909250933480.14282@luggage>
References: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>
	<4ABC718E.90908@thingy.com>
	<56F211C5E3F24F47B103EA1B253822BE044AAC99@vic-cr-ex1.staff.netspace.net.au>
	<alpine.DEB.2.00.0909250933480.14282@luggage>
Message-ID: <6b300f5d0909250223k4006b4ccq25cce86159c902f0@mail.gmail.com>

http://webtrace.info/asn?q=1234&submit=asn

2009/9/25 Ronan Mullally <ronan at iol.ie>

> Hi Andy,
>
> On Fri, 25 Sep 2009, Andy Saykao wrote:
>
> > This is why I needed to know what IP blocks belong to AS1234, so I could
> > find out how much traffic was actually coming from AS1234 on our
> > Internet link.
>
> Some (possibly all?) Whois servers can provide you with this information
> with:
>
>  whois -h whois.ripe.net -i origin AS1234
>
>  % Information related to '194.110.40.0/23AS1234'
>
>  route:        194.110.40.0/23
>  descr:        Imatran Voima Corporation
>  descr:        EUnet-FI aggregate
>  origin:       AS1234
>  mnt-by:       AS790-MNT
>  source:       RIPE # Filtered
>
>  % Information related to '194.110.44.0/23AS1234'
>
>  route:        194.110.44.0/23
>  descr:        Carelcomp Power
>  descr:        EUnet-FI aggregate
>  origin:       AS1234
>  mnt-by:       AS790-MNT
>  source:       RIPE # Filtered
>
>  % Information related to '193.110.32.0/21AS1234'
>
>  route:        193.110.32.0/21
>  descr:        Fortum
>  origin:       AS1234
>  mnt-by:       TE-ENERGY-NOC
>  source:       RIPE # Filtered
>
> (an inverse query looking for objects with an origin of AS1234).
>
> I don't know how definitive it is - I've queried several large AS and got
> nothing back.  It may be this functionality is only available in the RIPE
> whois server.  There's also no guarantee the results are going to be
> current or accurate.
>
>
> -Ronan
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



-- 
With best regards,
     Andrey 'sshd' Petrenko
     xmmp: sshd at jabber.org
     gtalk: andy.petrenko at gmail.com
     skype: andy.petrenko
     web: http://sshd.by

From Michael.Robson at manchester.ac.uk  Fri Sep 25 05:44:14 2009
From: Michael.Robson at manchester.ac.uk (Michael Robson)
Date: Fri, 25 Sep 2009 10:44:14 +0100
Subject: [c-nsp] EoMPLS v L2TPv3
Message-ID: <A4829031-5761-4641-BB69-0D8E3508B624@manchester.ac.uk>

What is the added benefit of running an EoMPLS pseudowire across an  
MPLS cloud over an L2TPv3 tunnel over the same cloud?


Michael
-- 

Michael Robson	| Tel: +44 (0) 161 275 6113
Networks		| Fax: +44 (0) 161 275 6120
Net North West	| Email: Michael.Robson at manchester.ac.uk






From simon at slimey.org  Fri Sep 25 05:54:27 2009
From: simon at slimey.org (Simon Lockhart)
Date: Fri, 25 Sep 2009 10:54:27 +0100
Subject: [c-nsp] EoMPLS v L2TPv3
In-Reply-To: <A4829031-5761-4641-BB69-0D8E3508B624@manchester.ac.uk>
References: <A4829031-5761-4641-BB69-0D8E3508B624@manchester.ac.uk>
Message-ID: <20090925095427.GR20581@virtual.bogons.net>

On Fri Sep 25, 2009 at 10:44:14AM +0100, Michael Robson wrote:
> What is the added benefit of running an EoMPLS pseudowire across an  
> MPLS cloud over an L2TPv3 tunnel over the same cloud?

In my experience, a difference in which feature is supported on the hardware
you've got. My gut feel is that EoMPLS has more hardware support than L2TPv3.

Simon
-- 
Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration *
   Director    |    * Domain & Web Hosting * Internet Consultancy * 
  Bogons Ltd   | * http://www.bogons.net/  *  Email: info at bogons.net  * 

From nick at inex.ie  Fri Sep 25 06:19:47 2009
From: nick at inex.ie (Nick Hilliard)
Date: Fri, 25 Sep 2009 11:19:47 +0100
Subject: [c-nsp] Which IP's belong to AS1234?
In-Reply-To: <alpine.DEB.2.00.0909250933480.14282@luggage>
References: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>	<4ABC718E.90908@thingy.com>	<56F211C5E3F24F47B103EA1B253822BE044AAC99@vic-cr-ex1.staff.netspace.net.au>
	<alpine.DEB.2.00.0909250933480.14282@luggage>
Message-ID: <4ABC9943.1060104@inex.ie>

On 25/09/2009 09:39, Ronan Mullally wrote:
> Some (possibly all?) Whois servers can provide you with this information
> with:

if you can bear a few moments of plugging the unpluggable, you can do all 
of this with irrtoolset's peval(1).

> cupcake:/Users/nick/irrtoolset/cruft-cleanout/src/peval% peval AS1234
> ({194.110.44.0/23, 194.110.40.0/23, 193.110.32.0/21})
cupcake:/Users/nick/irrtoolset/cruft-cleanout/src/peval%

(Yo Ronan!)

Nick

From jzp-cnsp at rsuc.gweep.net  Fri Sep 25 06:45:04 2009
From: jzp-cnsp at rsuc.gweep.net (Joe Provo)
Date: Fri, 25 Sep 2009 06:45:04 -0400
Subject: [c-nsp] Which IP's belong to AS1234?
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AAC99@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>
	<4ABC718E.90908@thingy.com>
	<56F211C5E3F24F47B103EA1B253822BE044AAC99@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <20090925104504.GA75672@gweep.net>

On Fri, Sep 25, 2009 at 06:12:22PM +1000, Andy Saykao wrote:
> Thanks for the reply guys.
> 
> What I'm trying to achieve is to monitor the bandwidth utilization on
> our Internet link. So for example we want to know how much bandwidth is
> being utilized by our customers so we can say "ah huh out of our 100M
> internet link, 90M of traffic is from youtube.com, so let's ask Google
> if they want to peer with us". 

Ah, who is using/announcince rather than any sense  of "ownership".
You want to look at the various *flow tools and platforms. Since this
is a cisco list and you presumable have cisco kit, look into netflow.
For education, check into sflow, jflow, etc.

For any useful data, you'd need to have a BGP table containing all the 
prefixes you care about.  Be aware that configuration for destination 
AS (as opposed to immediate neighbor AS) will still require post-
processing to be aggregated in any meaningful manner.

Cheers,

Joe


-- 
             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

From andy at nosignal.org  Fri Sep 25 06:52:09 2009
From: andy at nosignal.org (Andy Davidson)
Date: Fri, 25 Sep 2009 11:52:09 +0100
Subject: [c-nsp] Which IP's belong to AS1234?
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AAC99@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>
	<4ABC718E.90908@thingy.com>
	<56F211C5E3F24F47B103EA1B253822BE044AAC99@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <67C04D18-62A4-4C28-A454-B1547060F9F9@nosignal.org>


On 25 Sep 2009, at 09:12, Andy Saykao wrote:

> What I'm trying to achieve is to monitor the bandwidth utilization  
> on our Internet link. So for example we want to know how much  
> bandwidth is being utilized by our customers so we can say "ah huh  
> out of our 100M internet link, 90M of traffic is from youtube.com,  
> so let's ask Google if they want to peer with us".

That's a little different to the original question ;-) but I would  
recommend that you should look to see if your equipment can export  
netflow data about your traffic to a collector, and run analysis about  
aggregate flows to your target peers.

There are open source and commercial tools which can do this.  Poke me  
off list if you need specific info.



Best wishes,
Andy



-- 
Regards, Andy Davidson       +44 (0)20 7993 1700       www.netsumo.com
NetSumo  Specialist networks consultancy for ISPs, Whitelabel 24/7 NOC








From david.freedman at uk.clara.net  Fri Sep 25 07:03:01 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Fri, 25 Sep 2009 12:03:01 +0100
Subject: [c-nsp] EoMPLS v L2TPv3
In-Reply-To: <A4829031-5761-4641-BB69-0D8E3508B624@manchester.ac.uk>
References: <A4829031-5761-4641-BB69-0D8E3508B624@manchester.ac.uk>
Message-ID: <4ABCA365.1070108@uk.clara.net>

Wow, this is actually a tricky question, so I'll jot down some points
for you to think about from the top of my head (and anybody, please feel
free to correct these if they are wrong, they may be out of date)

EoMPLS:

 - Requires end-to-end MPLS LSP
 - Does not support path fragmentation (need wider MTU end-to-end)
 - Hardware support good
 - OAM available
 - Closer ties with MPLS-TE
 - some vendors have attachment circuit interworking
 - some hardware vendors may not be happy about attachment circuit MTU
mismatch


L2TPv3:

 - Only requires IP (but has some rudimentary security (Cookie))
 - "Path" Can be encrypted by IPSEC (this is actually a moot point, even
in a world where stuff like draft-raggarwa-mpls-ipsec wasn't
implemented, you can still encrypt the payloads of both technologies)
 - Not well supported in hardware, lots of restrictions
 - interworking support in hardware poor
 - lack of proper OAM



Dave.


Michael Robson wrote:
> What is the added benefit of running an EoMPLS pseudowire across an MPLS
> cloud over an L2TPv3 tunnel over the same cloud?
> 
> 
> Michael


From david.freedman at uk.clara.net  Fri Sep 25 07:03:01 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Fri, 25 Sep 2009 12:03:01 +0100
Subject: [c-nsp] EoMPLS v L2TPv3
In-Reply-To: <A4829031-5761-4641-BB69-0D8E3508B624@manchester.ac.uk>
References: <A4829031-5761-4641-BB69-0D8E3508B624@manchester.ac.uk>
Message-ID: <4ABCA365.1070108@uk.clara.net>

Wow, this is actually a tricky question, so I'll jot down some points
for you to think about from the top of my head (and anybody, please feel
free to correct these if they are wrong, they may be out of date)

EoMPLS:

 - Requires end-to-end MPLS LSP
 - Does not support path fragmentation (need wider MTU end-to-end)
 - Hardware support good
 - OAM available
 - Closer ties with MPLS-TE
 - some vendors have attachment circuit interworking
 - some hardware vendors may not be happy about attachment circuit MTU
mismatch


L2TPv3:

 - Only requires IP (but has some rudimentary security (Cookie))
 - "Path" Can be encrypted by IPSEC (this is actually a moot point, even
in a world where stuff like draft-raggarwa-mpls-ipsec wasn't
implemented, you can still encrypt the payloads of both technologies)
 - Not well supported in hardware, lots of restrictions
 - interworking support in hardware poor
 - lack of proper OAM



Dave.


Michael Robson wrote:
> What is the added benefit of running an EoMPLS pseudowire across an MPLS
> cloud over an L2TPv3 tunnel over the same cloud?
> 
> 
> Michael


From jgiles at e-dialog.com  Fri Sep 25 07:44:00 2009
From: jgiles at e-dialog.com (Jason Giles)
Date: Fri, 25 Sep 2009 07:44:00 -0400
Subject: [c-nsp] ASA5520 which image should I use?
In-Reply-To: <216854CA1A7F40098A49F3C959854852@int.convex.pt>
References: <00d401ca3d58$ab0e54e0$2208120a@am.thmulti.com>
	<216854CA1A7F40098A49F3C959854852@int.convex.pt>
Message-ID: <F666219FD7972B488B96751AD89464AE32B7B4CE@tigger.ad.e-dialog.com>

IF you need features in the 8.x code: Use 8.04(32) in the interim releases, if you are authenticating against a windows domain there are some key fixes in there.  

Love this tidbit of info in the 8.2.1 release notes:

"The caveats listed in Table 5 are recently-found caveats that were fixed in interim builds for previous versions; however, they are still open in Version 8.2 (they will be addressed in future releases)"

Guess a year is not long enough to release 8.05 or have all known previous bugs in 8.2.1.


-Jason


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Antonio Soares
Sent: Thursday, September 24, 2009 7:23 PM
To: 'Scott Granados'; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 which image should I use?

Stay away from 8.2. We are experiencing crashes since July (TAC case involved). Tomorrow we will install 8.2.1-10 to see if finally
we get rid of this.


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: quinta-feira, 24 de Setembro de 2009 21:51
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ASA5520 which image should I use?

Hi, I'm running a pair of ASA5520 devices as VPN concentrators.  Presently there is a software image installed that seems very old
and was actually shipped with the devices before I arrived on the scene.  I'm experiencing some issues with bringing up L2L tunnels
and figured that a firmware update was in order.  What version are folks using successfully?  I was thinking of going with the 8X
code but not sure which one to choose.  The features I'm using are very basic and include simple client access and LAN to LAN
access, I'm not using the anyconnect or web VPN features at this point.  Which image do you think would fit the bill the best?  Any
pointers would be appreciated.

Thank you
Scott

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From justin at justinshore.com  Fri Sep 25 09:09:16 2009
From: justin at justinshore.com (Justin Shore)
Date: Fri, 25 Sep 2009 08:09:16 -0500
Subject: [c-nsp] ASA5520 which image should I use?
In-Reply-To: <216854CA1A7F40098A49F3C959854852@int.convex.pt>
References: <00d401ca3d58$ab0e54e0$2208120a@am.thmulti.com>
	<216854CA1A7F40098A49F3C959854852@int.convex.pt>
Message-ID: <4ABCC0FC.1080808@justinshore.com>

Antonio Soares wrote:
> Stay away from 8.2. We are experiencing crashes since July (TAC case involved). Tomorrow we will install 8.2.1-10 to see if finally
> we get rid of this.

I've had good luck with 8.2.1-3 for our purposes.  Any 8.2 prior to that 
has that nasty coredump feature that writes to flash every time you do a 
'sh run' (RANCID users beware).

Justin




From NMaio at guesswho.com  Fri Sep 25 09:29:40 2009
From: NMaio at guesswho.com (NMaio at guesswho.com)
Date: Fri, 25 Sep 2009 09:29:40 -0400
Subject: [c-nsp] ASA5520 which image should I use?
In-Reply-To: <4ABCC0FC.1080808@justinshore.com>
References: <00d401ca3d58$ab0e54e0$2208120a@am.thmulti.com>
	<216854CA1A7F40098A49F3C959854852@int.convex.pt>
	<4ABCC0FC.1080808@justinshore.com>
Message-ID: <2AA600764E54964491083B1E0EC81A301E240C05F8@EXCLUS.nationala-1advertising.com>

Obviously everybody's experience has been different but I have been running very nicely on 8.0.x code.  I am running on the latest interim code on both ASAs and PIXs due to a security flaw though.    (knock on wood) It has been very stable.  7.2.4 code was very buggy for me.  I was upgrading probably every other month due to bugs until we jumped to 8.x code a while ago.

Justin,
I believe I saw your posts on the RANCID list and although the 8.2 coredump problem can be a pain you can modify your rancid script to ignore the coredump file when rancid does a show flash.  I do this for dhcp snooping since the db is small enough that I can keep it in flash.  (Yes I know about the warning that they give when you configure like this)  Every time a lease expires or a new lease is distributed the file is updated which would make rancid grab the change.   

Nick


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Justin Shore
Sent: Friday, September 25, 2009 9:09 AM
To: Antonio Soares
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 which image should I use?

Antonio Soares wrote:
> Stay away from 8.2. We are experiencing crashes since July (TAC case involved). Tomorrow we will install 8.2.1-10 to see if finally
> we get rid of this.

I've had good luck with 8.2.1-3 for our purposes.  Any 8.2 prior to that 
has that nasty coredump feature that writes to flash every time you do a 
'sh run' (RANCID users beware).

Justin



_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From rwest at zyedge.com  Fri Sep 25 09:45:24 2009
From: rwest at zyedge.com (Ryan West)
Date: Fri, 25 Sep 2009 09:45:24 -0400
Subject: [c-nsp] ASA5520 which image should I use?
In-Reply-To: <2AA600764E54964491083B1E0EC81A301E240C05F8@EXCLUS.nationala-1advertising.com>
References: <00d401ca3d58$ab0e54e0$2208120a@am.thmulti.com>
	<216854CA1A7F40098A49F3C959854852@int.convex.pt>
	<4ABCC0FC.1080808@justinshore.com>
	<2AA600764E54964491083B1E0EC81A301E240C05F8@EXCLUS.nationala-1advertising.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F9646@zy-ex1.zyedge.local>

Nick,

I agree with you on the earlier 7.2(4) releases, in particular 7.2(4)18 was bombing on us in multiple locations with site to site tunnels.  However, I think the same interim released bugs were in both trains.  In terms of bug fixes and general release times, 8.0(4)32 and 7.2(4)33 were released two days apart and have held up to any of the recent of PSIRT fixes.  I won't run 8.0(4)16 anywhere, just as I won't run 7.2(4)18.

I used the bugID Justin mentioned a while back to get 8.2.1(3) and it has proved to be stable for AnyConnect Essential customers.  I'm not sure why Cisco isn't releasing anything in the way of interim updates, the last was the 18th of May, I would rather not contact TAC for anything outside of the main train.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of NMaio at guesswho.com
Sent: Friday, September 25, 2009 9:30 AM
To: amsoares at netcabo.pt
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 which image should I use?

Obviously everybody's experience has been different but I have been running very nicely on 8.0.x code.  I am running on the latest interim code on both ASAs and PIXs due to a security flaw though.    (knock on wood) It has been very stable.  7.2.4 code was very buggy for me.  I was upgrading probably every other month due to bugs until we jumped to 8.x code a while ago.

Justin,
I believe I saw your posts on the RANCID list and although the 8.2 coredump problem can be a pain you can modify your rancid script to ignore the coredump file when rancid does a show flash.  I do this for dhcp snooping since the db is small enough that I can keep it in flash.  (Yes I know about the warning that they give when you configure like this)  Every time a lease expires or a new lease is distributed the file is updated which would make rancid grab the change.   

Nick



From cgriffin at ufl.edu  Fri Sep 25 10:32:14 2009
From: cgriffin at ufl.edu (Chris Griffin)
Date: Fri, 25 Sep 2009 10:32:14 -0400
Subject: [c-nsp] ASA5520 which image should I use?
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F9646@zy-ex1.zyedge.local>
References: <00d401ca3d58$ab0e54e0$2208120a@am.thmulti.com>
	<216854CA1A7F40098A49F3C959854852@int.convex.pt>
	<4ABCC0FC.1080808@justinshore.com>
	<2AA600764E54964491083B1E0EC81A301E240C05F8@EXCLUS.nationala-1advertising.com>
	<6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F9646@zy-ex1.zyedge.local>
Message-ID: <1253889134.25869.12.camel@empacher.cns.ufl.edu>

I have been told that going forward TAC is the only way to get interim
releases on 8.2 and newer code.  This wouldn't be bad if they put out
real releases more than once per year.  Crazy that it seems to be SOP
that Cisco, through making it difficult to get patches, encourages
running code on a security device with known security flaws.

Tnx
Chris

On Fri, 2009-09-25 at 09:45 -0400, Ryan West wrote:
> Nick,
> 
> I agree with you on the earlier 7.2(4) releases, in particular 7.2(4)18 was bombing on us in multiple locations with site to site tunnels.  However, I think the same interim released bugs were in both trains.  In terms of bug fixes and general release times, 8.0(4)32 and 7.2(4)33 were released two days apart and have held up to any of the recent of PSIRT fixes.  I won't run 8.0(4)16 anywhere, just as I won't run 7.2(4)18.
> 
> I used the bugID Justin mentioned a while back to get 8.2.1(3) and it has proved to be stable for AnyConnect Essential customers.  I'm not sure why Cisco isn't releasing anything in the way of interim updates, the last was the 18th of May, I would rather not contact TAC for anything outside of the main train.
> 
> -ryan
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of NMaio at guesswho.com
> Sent: Friday, September 25, 2009 9:30 AM
> To: amsoares at netcabo.pt
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASA5520 which image should I use?
> 
> Obviously everybody's experience has been different but I have been running very nicely on 8.0.x code.  I am running on the latest interim code on both ASAs and PIXs due to a security flaw though.    (knock on wood) It has been very stable.  7.2.4 code was very buggy for me.  I was upgrading probably every other month due to bugs until we jumped to 8.x code a while ago.
> 
> Justin,
> I believe I saw your posts on the RANCID list and although the 8.2 coredump problem can be a pain you can modify your rancid script to ignore the coredump file when rancid does a show flash.  I do this for dhcp snooping since the db is small enough that I can keep it in flash.  (Yes I know about the warning that they give when you configure like this)  Every time a lease expires or a new lease is distributed the file is updated which would make rancid grab the change.   
> 
> Nick
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
-- 
Chris Griffin                           cgriffin at ufl.edu
Sr. Network Engineer - CCNP             Phone: (352) 273-1051
CNS - Network Services                  Fax:   (352) 392-9440
University of Florida/FLR               Gainesville, FL 32611


From jfitz at Princeton.EDU  Fri Sep 25 10:33:44 2009
From: jfitz at Princeton.EDU (Jeff Fitzwater)
Date: Fri, 25 Sep 2009 10:33:44 -0400
Subject: [c-nsp] QOS mismatch for channel ports ??
Message-ID: <E564318C-4A6D-4B12-BE9A-0CB114710A9B@princeton.edu>

I have the following two ports on different modules and they have  
different QOS scheduling which stops them from being members of a  
channel group.

Is there a way to fix this by changing the QOS on one of the  
ports  ?   I wanted to keep the ports on separate boards if possible.

--------

TenGigabitEthernet12/6
  Model:                 WS-X6708-10GE
  Type:                  10Gbase-LR
  Speed:                 10000
  Duplex:                full
  Trunk encap. type:     802.1Q,ISL
  Trunk mode:            on,off,desirable,nonegotiate
  Channel:               yes
  Broadcast suppression: percentage(0-100)
  Flowcontrol:           rx-(off,on),tx-(off,on)
  Membership:            static
  Fast Start:            yes
  QOS scheduling:        rx-(8q4t), tx-(1p7q4t)
  QOS queueing mode:     rx-(cos,dscp), tx-(cos,dscp)
  CoS rewrite:           yes
  ToS rewrite:           yes
  Inline power:          no
  Inline power policing: no
  SPAN:                  source/destination
  UDLD                   yes
  Link Debounce:         yes
  Link Debounce Time:    yes
  Ports-in-ASIC (Sub-port ASIC) : 2-3,6,8 (6)
  Remote switch uplink:  no
  Dot1x:                 yes
  Port-Security:         yes
---------

TenGigabitEthernet7/4
  Model:                 VS-S720-10G
  Type:                  10Gbase-LR
  Speed:                 10000
  Duplex:                full
  Trunk encap. type:     802.1Q,ISL
  Trunk mode:            on,off,desirable,nonegotiate
  Channel:               yes
  Broadcast suppression: percentage(0-100)
  Flowcontrol:           rx-(off,on),tx-(off,on)
  Membership:            static
  Fast Start:            yes
  QOS scheduling:        rx-(2q4t), tx-(1p3q4t)
  QOS queueing mode:     rx-(cos), tx-(cos)
  CoS rewrite:           yes
  ToS rewrite:           yes
  Inline power:          no
  Inline power policing: no
  SPAN:                  source/destination
  UDLD                   yes
  Link Debounce:         yes
  Link Debounce Time:    yes
  Ports-in-ASIC (Sub-port ASIC) : 1-5 (3-4)
  Remote switch uplink:  no
  Dot1x:                 yes
  Port-Security:         yes
-----------------

Thanks in advance...


Jeff Fitzwater
OIT Network Systems
Princeton University

From cgriffin at ufl.edu  Fri Sep 25 10:59:47 2009
From: cgriffin at ufl.edu (Chris Griffin)
Date: Fri, 25 Sep 2009 10:59:47 -0400
Subject: [c-nsp] QOS mismatch for channel ports ??
In-Reply-To: <E564318C-4A6D-4B12-BE9A-0CB114710A9B@princeton.edu>
References: <E564318C-4A6D-4B12-BE9A-0CB114710A9B@princeton.edu>
Message-ID: <1253890787.25869.15.camel@empacher.cns.ufl.edu>

try "no mls qos channel-consistency" under the port channel...

On Fri, 2009-09-25 at 10:33 -0400, Jeff Fitzwater wrote:
> I have the following two ports on different modules and they have  
> different QOS scheduling which stops them from being members of a  
> channel group.
> 
> Is there a way to fix this by changing the QOS on one of the  
> ports  ?   I wanted to keep the ports on separate boards if possible.
> 
> --------
> 
> TenGigabitEthernet12/6
>   Model:                 WS-X6708-10GE
>   Type:                  10Gbase-LR
>   Speed:                 10000
>   Duplex:                full
>   Trunk encap. type:     802.1Q,ISL
>   Trunk mode:            on,off,desirable,nonegotiate
>   Channel:               yes
>   Broadcast suppression: percentage(0-100)
>   Flowcontrol:           rx-(off,on),tx-(off,on)
>   Membership:            static
>   Fast Start:            yes
>   QOS scheduling:        rx-(8q4t), tx-(1p7q4t)
>   QOS queueing mode:     rx-(cos,dscp), tx-(cos,dscp)
>   CoS rewrite:           yes
>   ToS rewrite:           yes
>   Inline power:          no
>   Inline power policing: no
>   SPAN:                  source/destination
>   UDLD                   yes
>   Link Debounce:         yes
>   Link Debounce Time:    yes
>   Ports-in-ASIC (Sub-port ASIC) : 2-3,6,8 (6)
>   Remote switch uplink:  no
>   Dot1x:                 yes
>   Port-Security:         yes
> ---------
> 
> TenGigabitEthernet7/4
>   Model:                 VS-S720-10G
>   Type:                  10Gbase-LR
>   Speed:                 10000
>   Duplex:                full
>   Trunk encap. type:     802.1Q,ISL
>   Trunk mode:            on,off,desirable,nonegotiate
>   Channel:               yes
>   Broadcast suppression: percentage(0-100)
>   Flowcontrol:           rx-(off,on),tx-(off,on)
>   Membership:            static
>   Fast Start:            yes
>   QOS scheduling:        rx-(2q4t), tx-(1p3q4t)
>   QOS queueing mode:     rx-(cos), tx-(cos)
>   CoS rewrite:           yes
>   ToS rewrite:           yes
>   Inline power:          no
>   Inline power policing: no
>   SPAN:                  source/destination
>   UDLD                   yes
>   Link Debounce:         yes
>   Link Debounce Time:    yes
>   Ports-in-ASIC (Sub-port ASIC) : 1-5 (3-4)
>   Remote switch uplink:  no
>   Dot1x:                 yes
>   Port-Security:         yes
> -----------------
> 
> Thanks in advance...
> 
> 
> Jeff Fitzwater
> OIT Network Systems
> Princeton University
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
-- 
Chris Griffin                           cgriffin at ufl.edu
Sr. Network Engineer - CCNP             Phone: (352) 273-1051
CNS - Network Services                  Fax:   (352) 392-9440
University of Florida/FLR               Gainesville, FL 32611


From gsgranados at comcast.net  Fri Sep 25 11:36:16 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Fri, 25 Sep 2009 08:36:16 -0700
Subject: [c-nsp] Which IP's belong to AS1234?
References: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au><4ABC718E.90908@thingy.com><56F211C5E3F24F47B103EA1B253822BE044AAC99@vic-cr-ex1.staff.netspace.net.au>
	<67C04D18-62A4-4C28-A454-B1547060F9F9@nosignal.org>
Message-ID: <003101ca3df5$f2ee8440$2208120a@am.thmulti.com>

Two words, "Arbor Networks".

http://www.arbornetworks.com

I've used their collector / reporting appliances in a large ISP setting and 
they were very good.  Expensive but if you need detailed reporting and 
traffic flow analysis these guys make some good tools.  Export netflow to 
the collector and Bob's your uncle.

Thanks
Scott



----- Original Message ----- 
From: "Andy Davidson" <andy at nosignal.org>
To: "Andy Saykao" <andy.saykao at staff.netspace.net.au>
Cc: <cisco-nsp at puck.nether.net>
Sent: Friday, September 25, 2009 3:52 AM
Subject: Re: [c-nsp] Which IP's belong to AS1234?


>
> On 25 Sep 2009, at 09:12, Andy Saykao wrote:
>
>> What I'm trying to achieve is to monitor the bandwidth utilization  on 
>> our Internet link. So for example we want to know how much  bandwidth is 
>> being utilized by our customers so we can say "ah huh  out of our 100M 
>> internet link, 90M of traffic is from youtube.com,  so let's ask Google 
>> if they want to peer with us".
>
> That's a little different to the original question ;-) but I would 
> recommend that you should look to see if your equipment can export 
> netflow data about your traffic to a collector, and run analysis about 
> aggregate flows to your target peers.
>
> There are open source and commercial tools which can do this.  Poke me 
> off list if you need specific info.
>
>
>
> Best wishes,
> Andy
>
>
>
> -- 
> Regards, Andy Davidson       +44 (0)20 7993 1700       www.netsumo.com
> NetSumo  Specialist networks consultancy for ISPs, Whitelabel 24/7 NOC
>
>
>
>
>
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From jfitz at Princeton.EDU  Fri Sep 25 11:41:01 2009
From: jfitz at Princeton.EDU (Jeff Fitzwater)
Date: Fri, 25 Sep 2009 11:41:01 -0400
Subject: [c-nsp] QOS mismatch for channel ports ??
In-Reply-To: <1253890787.25869.15.camel@empacher.cns.ufl.edu>
References: <E564318C-4A6D-4B12-BE9A-0CB114710A9B@princeton.edu>
	<1253890787.25869.15.camel@empacher.cns.ufl.edu>
Message-ID: <C3176BA2-1504-4407-A468-ED92CC7EB133@Princeton.EDU>

That command is not available on 12.2SXI but I see that I could just  
disable QOS per PORT.

Also I noticed this command which applies to mod 7 (supervisor) which  
modifies the scheduling, but it looks like I would have to disable it  
on the 7/4 port so it reverts back and matches the 12/6 scheduling.

----------------------

mls qos 10g-only

To enable quality of service (QoS) in 10g-only mode, in which only the  
supervisor engine's 10-Gigabit Ethernet uplink ports are used, use the  
mls qos 10g-only command in global configuration mode. To allow the  
use of all uplink ports, including the 1-Gigabit Ethernet ports, use  
the no form of this command.

mls qos 10g-only

no mls qos 10g-only

Syntax Description

This command has no arguments or keywords.

Command Default

All ports are active on the supervisor engine.

Command Modes

Global configuration (config)

Command History

Release
Modification
12.2(33)SXH

Support for this command was introduced on the Supervisor Engine  
720-10GE.


Usage Guidelines

When you enter the mls qos 10g-only command, a supervisor engine with  
both 1-Gigabit and 10-Gigabit Ethernet uplink ports reallocates the  
interface queue capacity to improve the performance of its 10-Gigabit  
Ethernet ports. The reallocation is possible only in 10g-only mode, in  
which the supervisor engine's 1-Gigabit Ethernet ports are not used.  
In the normal mode, when all supervisor engine ports are active, the  
queue structure is 2q4t on receive and 1p3q4t on transmit. In 10g-only  
mode, the queue structure is 8q4t on receive and 1p7q4t on transmit.


Note	To display detailed information about the queues, use the show  
queueing interface command.
When you switch between normal and 10g-only modes, any existing QoS  
configuration on the uplink ports is lost, and you must reconfigure  
QoS. In addition, service will be temporarily lost on the ports during  
the transition.

If you do not shut down the 1-Gigabit Ethernet ports before entering  
the mls qos 10g-only command, the mls qos 10g-only command shuts down  
the ports.

When you switch from 10g-only mode to normal mode, you must enter the  
no shutdown command on each of the 1-Gigabit Ethernet ports to resume  
QoS service on those ports.

In 10g-only mode, the 1-Gigabit Ethernet ports are visible, but they  
remain in an administratively down state.


----------------

I don't want to turn any knobs unless I really understand what they do.



Jeff


On Sep 25, 2009, at 10:59 AM, Chris Griffin wrote:

> try "no mls qos channel-consistency" under the port channel...
>
> On Fri, 2009-09-25 at 10:33 -0400, Jeff Fitzwater wrote:
>> I have the following two ports on different modules and they have
>> different QOS scheduling which stops them from being members of a
>> channel group.
>>
>> Is there a way to fix this by changing the QOS on one of the
>> ports  ?   I wanted to keep the ports on separate boards if possible.
>>
>> --------
>>
>> TenGigabitEthernet12/6
>>  Model:                 WS-X6708-10GE
>>  Type:                  10Gbase-LR
>>  Speed:                 10000
>>  Duplex:                full
>>  Trunk encap. type:     802.1Q,ISL
>>  Trunk mode:            on,off,desirable,nonegotiate
>>  Channel:               yes
>>  Broadcast suppression: percentage(0-100)
>>  Flowcontrol:           rx-(off,on),tx-(off,on)
>>  Membership:            static
>>  Fast Start:            yes
>>  QOS scheduling:        rx-(8q4t), tx-(1p7q4t)
>>  QOS queueing mode:     rx-(cos,dscp), tx-(cos,dscp)
>>  CoS rewrite:           yes
>>  ToS rewrite:           yes
>>  Inline power:          no
>>  Inline power policing: no
>>  SPAN:                  source/destination
>>  UDLD                   yes
>>  Link Debounce:         yes
>>  Link Debounce Time:    yes
>>  Ports-in-ASIC (Sub-port ASIC) : 2-3,6,8 (6)
>>  Remote switch uplink:  no
>>  Dot1x:                 yes
>>  Port-Security:         yes
>> ---------
>>
>> TenGigabitEthernet7/4
>>  Model:                 VS-S720-10G
>>  Type:                  10Gbase-LR
>>  Speed:                 10000
>>  Duplex:                full
>>  Trunk encap. type:     802.1Q,ISL
>>  Trunk mode:            on,off,desirable,nonegotiate
>>  Channel:               yes
>>  Broadcast suppression: percentage(0-100)
>>  Flowcontrol:           rx-(off,on),tx-(off,on)
>>  Membership:            static
>>  Fast Start:            yes
>>  QOS scheduling:        rx-(2q4t), tx-(1p3q4t)
>>  QOS queueing mode:     rx-(cos), tx-(cos)
>>  CoS rewrite:           yes
>>  ToS rewrite:           yes
>>  Inline power:          no
>>  Inline power policing: no
>>  SPAN:                  source/destination
>>  UDLD                   yes
>>  Link Debounce:         yes
>>  Link Debounce Time:    yes
>>  Ports-in-ASIC (Sub-port ASIC) : 1-5 (3-4)
>>  Remote switch uplink:  no
>>  Dot1x:                 yes
>>  Port-Security:         yes
>> -----------------
>>
>> Thanks in advance...
>>
>>
>> Jeff Fitzwater
>> OIT Network Systems
>> Princeton University
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> -- 
> Chris Griffin                           cgriffin at ufl.edu
> Sr. Network Engineer - CCNP             Phone: (352) 273-1051
> CNS - Network Services                  Fax:   (352) 392-9440
> University of Florida/FLR               Gainesville, FL 32611
>


From gsgranados at comcast.net  Fri Sep 25 11:47:17 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Fri, 25 Sep 2009 08:47:17 -0700
Subject: [c-nsp] More on Download hell, java,
	accessibility and Cisco's response!
Message-ID: <00d201ca3df7$79ebbf70$2208120a@am.thmulti.com>

Hi all,
I thought I would post my response that I received from a feedback message I 
sent after not being able to use the new download tool.  I'm encouraged by 
this response and will be sending Cisco detailed information on screen 
reader java interactions.  For the general concerns it looks like a non java 
release is in the works.

<MESSAGE FOLLOWS>

 Hello Scott,

Thank you for your feedback and we regret any inconvenience.

Could you please give us more insight on the difficulty you are facing
in downloading the software. Also provide some additional information
such as the specific steps in the download process where the screen
reader is inaccessible.

We are also working on a non Java download option in our upcoming
release.

Thanks so much for your time and patience.

Regards,
Meera




From justin at justinshore.com  Fri Sep 25 11:55:34 2009
From: justin at justinshore.com (Justin Shore)
Date: Fri, 25 Sep 2009 10:55:34 -0500
Subject: [c-nsp] ASA5520 which image should I use?
In-Reply-To: <2AA600764E54964491083B1E0EC81A301E240C05F8@EXCLUS.nationala-1advertising.com>
References: <00d401ca3d58$ab0e54e0$2208120a@am.thmulti.com>	<216854CA1A7F40098A49F3C959854852@int.convex.pt>
	<4ABCC0FC.1080808@justinshore.com>
	<2AA600764E54964491083B1E0EC81A301E240C05F8@EXCLUS.nationala-1advertising.com>
Message-ID: <4ABCE7F6.3030009@justinshore.com>

NMaio at guesswho.com wrote:
> Justin,
> I believe I saw your posts on the RANCID list and although the 8.2 coredump problem can be a pain you can modify your rancid script to ignore the coredump file when rancid does a show flash.  I do this for dhcp snooping since the db is small enough that I can keep it in flash.  (Yes I know about the warning that they give when you configure like this)  Every time a lease expires or a new lease is distributed the file is updated which would make rancid grab the change.   

Nick,

I could have modified a copy of the RANCID scripts to just use to work 
around the problem but that only addresses the RANCID problem.  I kicked 
it around and ultimately decided to just slow down the rate that RANCID 
checked that device while I worked with Cisco on a solution.

Modifying the RANCID scripts doesn't help address the bigger picture. 
The DE who programmed that feature to rewrite the file on disk with the 
exact same information each and every time the running-config was 
generated made a beginner programming mistake.  CF has a lifecycle of 
approximately 10,000 writes.  Running RANCID hourly (everybody picks 
their own times but we run hourly) results in CF module failure in about 
14 months.  It's hard to believe that something as simple as polling a 
router for some info can cause it have a hardware failure but in this 
case that's how the cookie crumbles.

The fix on Cisco's end was very simple and they had the bug addressed 
and rolled into an interim release in about 3 weeks (far exceeding my 
expectations so kudos to Cisco on that).

I will definitely keep in mind that possibly modifying the scripts if I 
ever have to write to flash regularly.  Hopefully I can avoid it though.

Justin


From NMaio at guesswho.com  Fri Sep 25 12:19:59 2009
From: NMaio at guesswho.com (NMaio at guesswho.com)
Date: Fri, 25 Sep 2009 12:19:59 -0400
Subject: [c-nsp] ASA5520 which image should I use?
In-Reply-To: <4ABCE7F6.3030009@justinshore.com>
References: <00d401ca3d58$ab0e54e0$2208120a@am.thmulti.com>
	<216854CA1A7F40098A49F3C959854852@int.convex.pt>
	<4ABCC0FC.1080808@justinshore.com>
	<2AA600764E54964491083B1E0EC81A301E240C05F8@EXCLUS.nationala-1advertising.com>
	<4ABCE7F6.3030009@justinshore.com>
Message-ID: <2AA600764E54964491083B1E0EC81A301E240C0732@EXCLUS.nationala-1advertising.com>

Justin,
I definitely see your point but it might be hard to generalize that all CF chips fail at 10000 writes.  Unless you know that Cisco uses a specific type of flash and the MTBF of that chip is 10000 writes.  Some CF chips are rated much higher than that.  
Regardless it is good that Cisco has fixed the coredump feature in 8.2 code.
Nick


-----Original Message-----
From: Justin Shore [mailto:justin at justinshore.com] 
Sent: Friday, September 25, 2009 11:56 AM
To: Nicholas Maio
Cc: amsoares at netcabo.pt; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 which image should I use?

NMaio at guesswho.com wrote:
> Justin,
> I believe I saw your posts on the RANCID list and although the 8.2 coredump problem can be a pain you can modify your rancid script to ignore the coredump file when rancid does a show flash.  I do this for dhcp snooping since the db is small enough that I can keep it in flash.  (Yes I know about the warning that they give when you configure like this)  Every time a lease expires or a new lease is distributed the file is updated which would make rancid grab the change.   

Nick,

I could have modified a copy of the RANCID scripts to just use to work 
around the problem but that only addresses the RANCID problem.  I kicked 
it around and ultimately decided to just slow down the rate that RANCID 
checked that device while I worked with Cisco on a solution.

Modifying the RANCID scripts doesn't help address the bigger picture. 
The DE who programmed that feature to rewrite the file on disk with the 
exact same information each and every time the running-config was 
generated made a beginner programming mistake.  CF has a lifecycle of 
approximately 10,000 writes.  Running RANCID hourly (everybody picks 
their own times but we run hourly) results in CF module failure in about 
14 months.  It's hard to believe that something as simple as polling a 
router for some info can cause it have a hardware failure but in this 
case that's how the cookie crumbles.

The fix on Cisco's end was very simple and they had the bug addressed 
and rolled into an interim release in about 3 weeks (far exceeding my 
expectations so kudos to Cisco on that).

I will definitely keep in mind that possibly modifying the scripts if I 
ever have to write to flash regularly.  Hopefully I can avoid it though.

Justin


From gsgranados at comcast.net  Fri Sep 25 12:25:55 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Fri, 25 Sep 2009 09:25:55 -0700
Subject: [c-nsp] Any gotchas in upgrading ASA5520 pairs?
Message-ID: <017801ca3dfc$dfbc6840$2208120a@am.thmulti.com>

Hi,
    I have two ASA 5520 devices in a active standby pair.  I'm presently at 
firmware 7.0.7 and ASDM 5.0 and want to upgrade to 7.2.4-33.  I've googled 
and found some detailed instructions and the process seems simple and 
standard, upload the image, change the boot vars, save and restart.  Is this 
correct?  Would the following work?
First, upgrade the standby, restart, once back up fail over to standby so 
the primary becomes standby and repeat?  Are there any issues with 
mismatched images that I will need to be concerned with while the two 
devices are in transition?  How about any gotchas from the upgrade of 7.0.7 
to 7.2.4 itself anything I need to know?  I didn't see any alerts in the 
directions but figured I should check here.  Any pointers would be 
appreciated.

Thank you
Scott


From rtrguike at gmail.com  Fri Sep 25 12:33:09 2009
From: rtrguike at gmail.com (Ruter Guike)
Date: Fri, 25 Sep 2009 13:33:09 -0300
Subject: [c-nsp] Ethernet Preamble and FCS on EoMPLS
Message-ID: <6cf7fb160909250933u4e80d5aak762ffdab59e64b8c@mail.gmail.com>

Hi List.

Is Cisco able to include Ethernet "preamble" and "FCS" within the mpls
packet, on EoMPLS? Is it configurable?

AFAIK, these fields are removed, by default, before encapsulating...

Thanks in advance.

Ruter

From jasongurtz at npumail.com  Fri Sep 25 12:36:41 2009
From: jasongurtz at npumail.com (Jason Gurtz)
Date: Fri, 25 Sep 2009 12:36:41 -0400
Subject: [c-nsp] FTP seems to work
Message-ID: <A92EAF652EC423438D55C14C60771C8701AD5B72@exchgsrv.nputilities.local>

I was about to write a little perl to further address the recent outcry
over the cisco.com Java misfeatures when lo, I discovered
ftp://download-sj.cisco.com will accept my cco login id/pass.  I poked
around and discovered /cisco/ios and /cisco/ciscosecure/pix seemed to have
what I'd be looking for.

Is this new or just a secret DL feature?

~JasonG

--

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3088 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090925/edc02003/attachment.bin>

From rwest at zyedge.com  Fri Sep 25 12:48:24 2009
From: rwest at zyedge.com (Ryan West)
Date: Fri, 25 Sep 2009 12:48:24 -0400
Subject: [c-nsp] Any gotchas in upgrading ASA5520 pairs?
In-Reply-To: <017801ca3dfc$dfbc6840$2208120a@am.thmulti.com>
References: <017801ca3dfc$dfbc6840$2208120a@am.thmulti.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F968D@zy-ex1.zyedge.local>

Scott,

I'm sure other people follow different methods, but I haven't run into any issues loading the code on both devices, rebooting the primary causing an immediate failover, waiting for the config sync messages on the new primary.  Once I see all interfaces as normal, I reload the primary and make sure the config sync messages show up again and verify all is well.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Friday, September 25, 2009 12:26 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Any gotchas in upgrading ASA5520 pairs?

Hi,
    I have two ASA 5520 devices in a active standby pair.  I'm presently at 
firmware 7.0.7 and ASDM 5.0 and want to upgrade to 7.2.4-33.  I've googled 
and found some detailed instructions and the process seems simple and 
standard, upload the image, change the boot vars, save and restart.  Is this 
correct?  Would the following work?
First, upgrade the standby, restart, once back up fail over to standby so 
the primary becomes standby and repeat?  Are there any issues with 
mismatched images that I will need to be concerned with while the two 
devices are in transition?  How about any gotchas from the upgrade of 7.0.7 
to 7.2.4 itself anything I need to know?  I didn't see any alerts in the 
directions but figured I should check here.  Any pointers would be 
appreciated.

Thank you
Scott

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From moua0100 at umn.edu  Fri Sep 25 12:49:47 2009
From: moua0100 at umn.edu (Ge Moua)
Date: Fri, 25 Sep 2009 11:49:47 -0500
Subject: [c-nsp] EoMPLS v L2TPv3
In-Reply-To: <4ABCA365.1070108@uk.clara.net>
References: <A4829031-5761-4641-BB69-0D8E3508B624@manchester.ac.uk>
	<4ABCA365.1070108@uk.clara.net>
Message-ID: <4ABCF4AB.7060301@umn.edu>

David Freedman-
Do you have a preference of one over the other?  I've been thinking 
about the option of replacing our L2TPv3 deployment with EoMPLS (ie, 
Cisco's ATOM model).

We are using Cisco 7203 with NSE engine for L2TPv3 acceleration; but I'm 
not a big fan of this platform; we have 3bxl-sup720/cat6k at the core 
that can do MPLS in hardware; I was just thinking of using GRE to 
encapsulate the MPLS packet over to the spoke sites (thereby bypassing 
the need to do MPLS end-to-end); this would allow EoMPLS over service 
providers' native IP infrastructure.

Feedback?



Regards,
Ge Moua | Email: moua0100 at umn.edu

Network Design Engineer
University of Minnesota | Networking & Telecommunications Services



David Freedman wrote:
> Wow, this is actually a tricky question, so I'll jot down some points
> for you to think about from the top of my head (and anybody, please feel
> free to correct these if they are wrong, they may be out of date)
>
> EoMPLS:
>
>  - Requires end-to-end MPLS LSP
>  - Does not support path fragmentation (need wider MTU end-to-end)
>  - Hardware support good
>  - OAM available
>  - Closer ties with MPLS-TE
>  - some vendors have attachment circuit interworking
>  - some hardware vendors may not be happy about attachment circuit MTU
> mismatch
>
>
> L2TPv3:
>
>  - Only requires IP (but has some rudimentary security (Cookie))
>  - "Path" Can be encrypted by IPSEC (this is actually a moot point, even
> in a world where stuff like draft-raggarwa-mpls-ipsec wasn't
> implemented, you can still encrypt the payloads of both technologies)
>  - Not well supported in hardware, lots of restrictions
>  - interworking support in hardware poor
>  - lack of proper OAM
>
>
>
> Dave.
>
>
> Michael Robson wrote:
>   
>> What is the added benefit of running an EoMPLS pseudowire across an MPLS
>> cloud over an L2TPv3 tunnel over the same cloud?
>>
>>
>> Michael
>>     
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   

From gert at greenie.muc.de  Fri Sep 25 12:54:51 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 25 Sep 2009 18:54:51 +0200
Subject: [c-nsp] EoMPLS v L2TPv3
In-Reply-To: <4ABCF4AB.7060301@umn.edu>
References: <A4829031-5761-4641-BB69-0D8E3508B624@manchester.ac.uk>
	<4ABCA365.1070108@uk.clara.net> <4ABCF4AB.7060301@umn.edu>
Message-ID: <20090925165451.GT1508@greenie.muc.de>

Hi,

On Fri, Sep 25, 2009 at 11:49:47AM -0500, Ge Moua wrote:
> We are using Cisco 7203 with NSE engine for L2TPv3 acceleration; but I'm 
> not a big fan of this platform; we have 3bxl-sup720/cat6k at the core 
> that can do MPLS in hardware; I was just thinking of using GRE to 
> encapsulate the MPLS packet over to the spoke sites (thereby bypassing 
> the need to do MPLS end-to-end); this would allow EoMPLS over service 
> providers' native IP infrastructure.
> 
> Feedback?

PFC3b cannot do MPLS-over-GRE

(... at least not without the help of a SIP or ES line card)

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090925/cb698d26/attachment-0001.bin>

From david.freedman at uk.clara.net  Fri Sep 25 12:56:54 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Fri, 25 Sep 2009 17:56:54 +0100
Subject: [c-nsp] EoMPLS v L2TPv3
In-Reply-To: <4ABCF4AB.7060301@umn.edu>
References: <A4829031-5761-4641-BB69-0D8E3508B624@manchester.ac.uk>
	<4ABCA365.1070108@uk.clara.net> <4ABCF4AB.7060301@umn.edu>
Message-ID: <4ABCF656.9080208@uk.clara.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think the choice is simple.

If you have a "native" MPLS backbone, use EoMPLS.

If you don't, then don't, use L2TPv3, please don't do MPLSoGRE,
it is more trouble than it is worth.

That said, can you not build out a native MPLS network? does your
provider not give you the ability to do this?

Dave.


Ge Moua wrote:
> David Freedman-
> Do you have a preference of one over the other?  I've been thinking
> about the option of replacing our L2TPv3 deployment with EoMPLS (ie,
> Cisco's ATOM model).
> 
> We are using Cisco 7203 with NSE engine for L2TPv3 acceleration; but I'm
> not a big fan of this platform; we have 3bxl-sup720/cat6k at the core
> that can do MPLS in hardware; I was just thinking of using GRE to
> encapsulate the MPLS packet over to the spoke sites (thereby bypassing
> the need to do MPLS end-to-end); this would allow EoMPLS over service
> providers' native IP infrastructure.
> 
> Feedback?
> 
> 
> 
> Regards,
> Ge Moua | Email: moua0100 at umn.edu
> 
> Network Design Engineer
> University of Minnesota | Networking & Telecommunications Services
> 
> 
> 
> David Freedman wrote:
>> Wow, this is actually a tricky question, so I'll jot down some points
>> for you to think about from the top of my head (and anybody, please feel
>> free to correct these if they are wrong, they may be out of date)
>>
>> EoMPLS:
>>
>>  - Requires end-to-end MPLS LSP
>>  - Does not support path fragmentation (need wider MTU end-to-end)
>>  - Hardware support good
>>  - OAM available
>>  - Closer ties with MPLS-TE
>>  - some vendors have attachment circuit interworking
>>  - some hardware vendors may not be happy about attachment circuit MTU
>> mismatch
>>
>>
>> L2TPv3:
>>
>>  - Only requires IP (but has some rudimentary security (Cookie))
>>  - "Path" Can be encrypted by IPSEC (this is actually a moot point, even
>> in a world where stuff like draft-raggarwa-mpls-ipsec wasn't
>> implemented, you can still encrypt the payloads of both technologies)
>>  - Not well supported in hardware, lots of restrictions
>>  - interworking support in hardware poor
>>  - lack of proper OAM
>>
>>
>>
>> Dave.
>>
>>
>> Michael Robson wrote:
>>  
>>> What is the added benefit of running an EoMPLS pseudowire across an MPLS
>>> cloud over an L2TPv3 tunnel over the same cloud?
>>>
>>>
>>> Michael
>>>     
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>   

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq89lUACgkQtFWeqpgEZrJgJQCgyiBbfxBZocdqUj438BmceLZh
fI8Anjz17oKLUcgsVlU4Xezwwhm8CAn6
=R75n
-----END PGP SIGNATURE-----

From nick at inex.ie  Fri Sep 25 12:59:56 2009
From: nick at inex.ie (Nick Hilliard)
Date: Fri, 25 Sep 2009 17:59:56 +0100
Subject: [c-nsp] FTP seems to work
In-Reply-To: <A92EAF652EC423438D55C14C60771C8701AD5B72@exchgsrv.nputilities.local>
References: <A92EAF652EC423438D55C14C60771C8701AD5B72@exchgsrv.nputilities.local>
Message-ID: <4ABCF70C.6070509@inex.ie>

On 25/09/2009 17:36, Jason Gurtz wrote:
> I was about to write a little perl to further address the recent outcry
> over the cisco.com Java misfeatures when lo, I discovered
> ftp://download-sj.cisco.com will accept my cco login id/pass.  I poked
> around and discovered /cisco/ios and /cisco/ciscosecure/pix seemed to have
> what I'd be looking for.
>
> Is this new or just a secret DL feature?

not at all.  This is ftp.cisco.com - the original download area which was 
available before http even existed.

> pixiedust:/home/nick> host ftp.cisco.com |grep address
> ftp.cisco.com has address 198.133.219.241
> pixiedust:/home/nick> host download-sj.cisco.com | grep address
> download-sj.cisco.com has address 198.133.219.241

You won't find crypto images there, but it has lots of other stuff, and is 
massively easier to negotiate than the web site.

Nick


From tvarriale at comcast.net  Fri Sep 25 13:08:31 2009
From: tvarriale at comcast.net (Tony Varriale)
Date: Fri, 25 Sep 2009 12:08:31 -0500
Subject: [c-nsp] Any gotchas in upgrading ASA5520 pairs?
References: <017801ca3dfc$dfbc6840$2208120a@am.thmulti.com>
	<6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F968D@zy-ex1.zyedge.local>
Message-ID: <91211E3F5F1547E4ADA7EA4C145B4B89@flamdt01>

I would recommend forcing the failover from the CLI.

tv
----- Original Message ----- 
From: "Ryan West" <rwest at zyedge.com>
To: "Scott Granados" <gsgranados at comcast.net>; <cisco-nsp at puck.nether.net>
Sent: Friday, September 25, 2009 11:48 AM
Subject: Re: [c-nsp] Any gotchas in upgrading ASA5520 pairs?


> Scott,
>
> I'm sure other people follow different methods, but I haven't run into any 
> issues loading the code on both devices, rebooting the primary causing an 
> immediate failover, waiting for the config sync messages on the new 
> primary.  Once I see all interfaces as normal, I reload the primary and 
> make sure the config sync messages show up again and verify all is well.
>
> -ryan
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
> Sent: Friday, September 25, 2009 12:26 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Any gotchas in upgrading ASA5520 pairs?
>
> Hi,
>    I have two ASA 5520 devices in a active standby pair.  I'm presently at
> firmware 7.0.7 and ASDM 5.0 and want to upgrade to 7.2.4-33.  I've googled
> and found some detailed instructions and the process seems simple and
> standard, upload the image, change the boot vars, save and restart.  Is 
> this
> correct?  Would the following work?
> First, upgrade the standby, restart, once back up fail over to standby so
> the primary becomes standby and repeat?  Are there any issues with
> mismatched images that I will need to be concerned with while the two
> devices are in transition?  How about any gotchas from the upgrade of 
> 7.0.7
> to 7.2.4 itself anything I need to know?  I didn't see any alerts in the
> directions but figured I should check here.  Any pointers would be
> appreciated.
>
> Thank you
> Scott
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From mail4hh at pobox.com  Fri Sep 25 13:09:17 2009
From: mail4hh at pobox.com (Hector Herrera)
Date: Fri, 25 Sep 2009 10:09:17 -0700
Subject: [c-nsp] FTP seems to work
In-Reply-To: <A92EAF652EC423438D55C14C60771C8701AD5B72@exchgsrv.nputilities.local>
References: <A92EAF652EC423438D55C14C60771C8701AD5B72@exchgsrv.nputilities.local>
Message-ID: <c7ef7cf70909251009i6f45747aj55f6189e799e646f@mail.gmail.com>

On Fri, Sep 25, 2009 at 9:36 AM, Jason Gurtz <jasongurtz at npumail.com> wrote:
> I was about to write a little perl to further address the recent outcry
> over the cisco.com Java misfeatures when lo, I discovered
> ftp://download-sj.cisco.com will accept my cco login id/pass. ?I poked
> around and discovered /cisco/ios and /cisco/ciscosecure/pix seemed to have
> what I'd be looking for.
>
> Is this new or just a secret DL feature?
>
> ~JasonG

Either it's now fixed, or my account without a maintenance contract
can't see it.

Hector

From NMaio at guesswho.com  Fri Sep 25 13:19:45 2009
From: NMaio at guesswho.com (NMaio at guesswho.com)
Date: Fri, 25 Sep 2009 13:19:45 -0400
Subject: [c-nsp] Any gotchas in upgrading ASA5520 pairs?
In-Reply-To: <017801ca3dfc$dfbc6840$2208120a@am.thmulti.com>
References: <017801ca3dfc$dfbc6840$2208120a@am.thmulti.com>
Message-ID: <2AA600764E54964491083B1E0EC81A301E240C076A@EXCLUS.nationala-1advertising.com>

Scott,
Not sure if is a concern for you but upgrading from 7.0 to 7.2 does not allow a zero downtime upgrade.  Check out the section " Performing Zero Downtime Upgrades for Failover Pairs" on the following link:
http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/mswlicfg.html
Nick


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Friday, September 25, 2009 12:26 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Any gotchas in upgrading ASA5520 pairs?

Hi,
    I have two ASA 5520 devices in a active standby pair.  I'm presently at 
firmware 7.0.7 and ASDM 5.0 and want to upgrade to 7.2.4-33.  I've googled 
and found some detailed instructions and the process seems simple and 
standard, upload the image, change the boot vars, save and restart.  Is this 
correct?  Would the following work?
First, upgrade the standby, restart, once back up fail over to standby so 
the primary becomes standby and repeat?  Are there any issues with 
mismatched images that I will need to be concerned with while the two 
devices are in transition?  How about any gotchas from the upgrade of 7.0.7 
to 7.2.4 itself anything I need to know?  I didn't see any alerts in the 
directions but figured I should check here.  Any pointers would be 
appreciated.

Thank you
Scott

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From dwinkworth at att.net  Fri Sep 25 12:23:26 2009
From: dwinkworth at att.net (Derick Winkworth)
Date: Fri, 25 Sep 2009 09:23:26 -0700 (PDT)
Subject: [c-nsp] BFD static in VRF...
In-Reply-To: <00d201ca3df7$79ebbf70$2208120a@am.thmulti.com>
References: <00d201ca3df7$79ebbf70$2208120a@am.thmulti.com>
Message-ID: <36073.41510.qm@web180013.mail.gq1.yahoo.com>

Anyone else try doing this?? I'm on 12.2(33)SRC4 on a 7200 w/NPE-G2 and for some reason the vrf option in "ip route static bfd" is not showing up... I don't see anything in the release notes about this or in bug toolkit...

Anyone thoughts?

From moua0100 at umn.edu  Fri Sep 25 13:36:37 2009
From: moua0100 at umn.edu (Ge Moua)
Date: Fri, 25 Sep 2009 12:36:37 -0500
Subject: [c-nsp] EoMPLS v L2TPv3
In-Reply-To: <20090925165451.GT1508@greenie.muc.de>
References: <A4829031-5761-4641-BB69-0D8E3508B624@manchester.ac.uk>
	<4ABCA365.1070108@uk.clara.net> <4ABCF4AB.7060301@umn.edu>
	<20090925165451.GT1508@greenie.muc.de>
Message-ID: <4ABCFFA5.9020209@umn.edu>

Gert-
what about the 3cxl; we have some of those on hand too.

Regards,
Ge Moua | Email: moua0100 at umn.edu

Network Design Engineer
University of Minnesota | Networking & Telecommunications Services



Gert Doering wrote:
> Hi,
>
> On Fri, Sep 25, 2009 at 11:49:47AM -0500, Ge Moua wrote:
>   
>> We are using Cisco 7203 with NSE engine for L2TPv3 acceleration; but I'm 
>> not a big fan of this platform; we have 3bxl-sup720/cat6k at the core 
>> that can do MPLS in hardware; I was just thinking of using GRE to 
>> encapsulate the MPLS packet over to the spoke sites (thereby bypassing 
>> the need to do MPLS end-to-end); this would allow EoMPLS over service 
>> providers' native IP infrastructure.
>>
>> Feedback?
>>     
>
> PFC3b cannot do MPLS-over-GRE
>
> (... at least not without the help of a SIP or ES line card)
>
> gert
>   

From lists at howells.me  Fri Sep 25 13:47:01 2009
From: lists at howells.me (Alex Howells)
Date: Fri, 25 Sep 2009 18:47:01 +0100
Subject: [c-nsp] Which IP's belong to AS1234?
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AAC99@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>	<4ABC718E.90908@thingy.com>
	<56F211C5E3F24F47B103EA1B253822BE044AAC99@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <4ABD0215.20407@howells.me>

Andy Saykao wrote:
> This is why I needed to know what IP blocks belong to AS1234, so I could
> find out how much traffic was actually coming from AS1234 on our
> Internet link.

What you actually want is Netflow (or JFlow, sFlow, etc) with a suitably
smart collector, which will provide you with all of this information and
more so that you can make informed peering decisions.

HTH,
Alex

From Reinhold.Fischer at gmx.net  Fri Sep 25 13:50:23 2009
From: Reinhold.Fischer at gmx.net (Reinhold Fischer)
Date: Fri, 25 Sep 2009 19:50:23 +0200
Subject: [c-nsp] Ethernet Preamble and FCS on EoMPLS
In-Reply-To: <6cf7fb160909250933u4e80d5aak762ffdab59e64b8c@mail.gmail.com>
References: <6cf7fb160909250933u4e80d5aak762ffdab59e64b8c@mail.gmail.com>
Message-ID: <20090925175023.GA13601@fart>

On Fri, Sep 25, 2009 at 01:33:09PM -0300, Ruter Guike wrote:
> Hi List.
> 
> Is Cisco able to include Ethernet "preamble" and "FCS" within the mpls
> packet, on EoMPLS? Is it configurable?
> 
> AFAIK, these fields are removed, by default, before encapsulating...
> 

RFC4448 (Encapsulation Methods for Transport of Ethernet
over MPLS Networks) specifies that preamble and FCS is not
transported. There is RFC4720 (Pseudowire Emulation
Edge-to-Edge (PWE3) Frame Check Sequence Retention) but to
my knowledge it is not implemented in IOS yet.  

What would be the benefit of transporting the Ethernet preamble?

hth

Reinhold

From jasongurtz at npumail.com  Fri Sep 25 13:53:57 2009
From: jasongurtz at npumail.com (Jason Gurtz)
Date: Fri, 25 Sep 2009 13:53:57 -0400
Subject: [c-nsp] FTP seems to work
In-Reply-To: <4ABCF70C.6070509@inex.ie>
References: <A92EAF652EC423438D55C14C60771C8701AD5B72@exchgsrv.nputilities.local>
	<4ABCF70C.6070509@inex.ie>
Message-ID: <A92EAF652EC423438D55C14C60771C8701AD5B89@exchgsrv.nputilities.local>

> You won't find crypto images there, but it has lots of other stuff, and
> is massively easier to negotiate than the web site.

Ahh yes, thanks for the clarification, that would explain the missing k9

Suckage...back to the perl idea...

~JasonG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3088 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090925/275c7206/attachment.bin>

From gsgranados at comcast.net  Fri Sep 25 14:07:18 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Fri, 25 Sep 2009 11:07:18 -0700
Subject: [c-nsp] Any gotchas in upgrading ASA5520 pairs?
References: <017801ca3dfc$dfbc6840$2208120a@am.thmulti.com>
	<2AA600764E54964491083B1E0EC81A301E240C076A@EXCLUS.nationala-1advertising.com>
Message-ID: <022801ca3e0b$0af289f0$2208120a@am.thmulti.com>

Hi, thanks for the link.  So it looks like I was close.  Am I reading this 
right in that I have to upgrade from 7.0 to 7.1 first then to 7.2?

Thanks
Scott

----- Original Message ----- 
From: <NMaio at guesswho.com>
To: <gsgranados at comcast.net>; <cisco-nsp at puck.nether.net>
Sent: Friday, September 25, 2009 10:19 AM
Subject: RE: [c-nsp] Any gotchas in upgrading ASA5520 pairs?


Scott,
Not sure if is a concern for you but upgrading from 7.0 to 7.2 does not 
allow a zero downtime upgrade.  Check out the section " Performing Zero 
Downtime Upgrades for Failover Pairs" on the following link:
http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/mswlicfg.html
Nick


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net 
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Friday, September 25, 2009 12:26 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Any gotchas in upgrading ASA5520 pairs?

Hi,
    I have two ASA 5520 devices in a active standby pair.  I'm presently at
firmware 7.0.7 and ASDM 5.0 and want to upgrade to 7.2.4-33.  I've googled
and found some detailed instructions and the process seems simple and
standard, upload the image, change the boot vars, save and restart.  Is this
correct?  Would the following work?
First, upgrade the standby, restart, once back up fail over to standby so
the primary becomes standby and repeat?  Are there any issues with
mismatched images that I will need to be concerned with while the two
devices are in transition?  How about any gotchas from the upgrade of 7.0.7
to 7.2.4 itself anything I need to know?  I didn't see any alerts in the
directions but figured I should check here.  Any pointers would be
appreciated.

Thank you
Scott

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From NMaio at guesswho.com  Fri Sep 25 14:15:52 2009
From: NMaio at guesswho.com (NMaio at guesswho.com)
Date: Fri, 25 Sep 2009 14:15:52 -0400
Subject: [c-nsp] Any gotchas in upgrading ASA5520 pairs?
In-Reply-To: <022801ca3e0b$0af289f0$2208120a@am.thmulti.com>
References: <017801ca3dfc$dfbc6840$2208120a@am.thmulti.com>
	<2AA600764E54964491083B1E0EC81A301E240C076A@EXCLUS.nationala-1advertising.com>
	<022801ca3e0b$0af289f0$2208120a@am.thmulti.com>
Message-ID: <2AA600764E54964491083B1E0EC81A301E240C07AD@EXCLUS.nationala-1advertising.com>

Yes that is the recommended procedure.  

"You can upgrade from the last minor release of the previous version to the next major release.
For example, you can upgrade from 7.9 to 8.0, assuming that 7.9 is the last minor version in the 7.x release."

Nick

-----Original Message-----
From: Scott Granados [mailto:gsgranados at comcast.net] 
Sent: Friday, September 25, 2009 2:07 PM
To: Nicholas Maio; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Any gotchas in upgrading ASA5520 pairs?

Hi, thanks for the link.  So it looks like I was close.  Am I reading this 
right in that I have to upgrade from 7.0 to 7.1 first then to 7.2?

Thanks
Scott

----- Original Message ----- 
From: <NMaio at guesswho.com>
To: <gsgranados at comcast.net>; <cisco-nsp at puck.nether.net>
Sent: Friday, September 25, 2009 10:19 AM
Subject: RE: [c-nsp] Any gotchas in upgrading ASA5520 pairs?


Scott,
Not sure if is a concern for you but upgrading from 7.0 to 7.2 does not 
allow a zero downtime upgrade.  Check out the section " Performing Zero 
Downtime Upgrades for Failover Pairs" on the following link:
http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/mswlicfg.html
Nick


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net 
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Friday, September 25, 2009 12:26 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Any gotchas in upgrading ASA5520 pairs?

Hi,
    I have two ASA 5520 devices in a active standby pair.  I'm presently at
firmware 7.0.7 and ASDM 5.0 and want to upgrade to 7.2.4-33.  I've googled
and found some detailed instructions and the process seems simple and
standard, upload the image, change the boot vars, save and restart.  Is this
correct?  Would the following work?
First, upgrade the standby, restart, once back up fail over to standby so
the primary becomes standby and repeat?  Are there any issues with
mismatched images that I will need to be concerned with while the two
devices are in transition?  How about any gotchas from the upgrade of 7.0.7
to 7.2.4 itself anything I need to know?  I didn't see any alerts in the
directions but figured I should check here.  Any pointers would be
appreciated.

Thank you
Scott

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From NMaio at guesswho.com  Fri Sep 25 14:21:10 2009
From: NMaio at guesswho.com (NMaio at guesswho.com)
Date: Fri, 25 Sep 2009 14:21:10 -0400
Subject: [c-nsp] Any gotchas in upgrading ASA5520 pairs?
References: <017801ca3dfc$dfbc6840$2208120a@am.thmulti.com>
	<2AA600764E54964491083B1E0EC81A301E240C076A@EXCLUS.nationala-1advertising.com>
	<022801ca3e0b$0af289f0$2208120a@am.thmulti.com> 
Message-ID: <2AA600764E54964491083B1E0EC81A301E240C07B2@EXCLUS.nationala-1advertising.com>

Oops wrong quote.

This is the one I intended to send you since you are not going to 8.x code.

"For example, you can upgrade from 7.0 to 7.1. Upgrading from 7.0 directly to 7.2 is not supported for zero-downtime upgrades; you must first upgrade to 7.1."

-----Original Message-----
From: Nicholas Maio 
Sent: Friday, September 25, 2009 2:16 PM
To: 'Scott Granados'; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Any gotchas in upgrading ASA5520 pairs?

Yes that is the recommended procedure.  

"You can upgrade from the last minor release of the previous version to the next major release.
For example, you can upgrade from 7.9 to 8.0, assuming that 7.9 is the last minor version in the 7.x release."

Nick

-----Original Message-----
From: Scott Granados [mailto:gsgranados at comcast.net] 
Sent: Friday, September 25, 2009 2:07 PM
To: Nicholas Maio; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Any gotchas in upgrading ASA5520 pairs?

Hi, thanks for the link.  So it looks like I was close.  Am I reading this 
right in that I have to upgrade from 7.0 to 7.1 first then to 7.2?

Thanks
Scott

----- Original Message ----- 
From: <NMaio at guesswho.com>
To: <gsgranados at comcast.net>; <cisco-nsp at puck.nether.net>
Sent: Friday, September 25, 2009 10:19 AM
Subject: RE: [c-nsp] Any gotchas in upgrading ASA5520 pairs?


Scott,
Not sure if is a concern for you but upgrading from 7.0 to 7.2 does not 
allow a zero downtime upgrade.  Check out the section " Performing Zero 
Downtime Upgrades for Failover Pairs" on the following link:
http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/mswlicfg.html
Nick


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net 
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Friday, September 25, 2009 12:26 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Any gotchas in upgrading ASA5520 pairs?

Hi,
    I have two ASA 5520 devices in a active standby pair.  I'm presently at
firmware 7.0.7 and ASDM 5.0 and want to upgrade to 7.2.4-33.  I've googled
and found some detailed instructions and the process seems simple and
standard, upload the image, change the boot vars, save and restart.  Is this
correct?  Would the following work?
First, upgrade the standby, restart, once back up fail over to standby so
the primary becomes standby and repeat?  Are there any issues with
mismatched images that I will need to be concerned with while the two
devices are in transition?  How about any gotchas from the upgrade of 7.0.7
to 7.2.4 itself anything I need to know?  I didn't see any alerts in the
directions but figured I should check here.  Any pointers would be
appreciated.

Thank you
Scott

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From A.L.M.Buxey at lboro.ac.uk  Fri Sep 25 14:57:28 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Fri, 25 Sep 2009 19:57:28 +0100
Subject: [c-nsp] More on Download hell, java,
	accessibility and Cisco's	response!
In-Reply-To: <00d201ca3df7$79ebbf70$2208120a@am.thmulti.com>
References: <00d201ca3df7$79ebbf70$2208120a@am.thmulti.com>
Message-ID: <20090925185728.GA28175@lboro.ac.uk>

Hi,

> I thought I would post my response that I received from a feedback 
> message I sent after not being able to use the new download tool.  I'm 
> encouraged by this response and will be sending Cisco detailed 
> information on screen reader java interactions.  For the general concerns 
> it looks like a non java release is in the works.

yep - I've now received 3 replies to the low scores and comments I have
given in the download questionaire.  not only is there the issue with filenames
on unix (if you choose a directory to save things in) but also theres a 
no path = no file issue too. which isnt amusing after you think you've
just downloaded 5 IOS releases to undertake some work.

anyway, yes. non java option looks like its coming...

alan

From wmaton at ryouko.imsb.nrc.ca  Fri Sep 25 15:23:51 2009
From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor)
Date: Fri, 25 Sep 2009 15:23:51 -0400 (EDT)
Subject: [c-nsp] More on Download hell, java,
 accessibility and Cisco's response!
In-Reply-To: <20090925185728.GA28175@lboro.ac.uk>
References: <00d201ca3df7$79ebbf70$2208120a@am.thmulti.com>
	<20090925185728.GA28175@lboro.ac.uk>
Message-ID: <Pine.LNX.4.64.0909251522550.23057@ryouko.imsb.nrc.ca>

On Fri, 25 Sep 2009, Alan Buxey wrote:

[snip]
> no path = no file issue too. which isnt amusing after you think you've
> just downloaded 5 IOS releases to undertake some work.
>
> anyway, yes. non java option looks like its coming...

For the impatient, I found this:

http://userscripts.org/scripts/show/58082

Works for me, that is until something else gets 'fixed'.

wfms

From peter at rathlev.dk  Fri Sep 25 16:21:32 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Fri, 25 Sep 2009 22:21:32 +0200
Subject: [c-nsp] EoMPLS v L2TPv3
In-Reply-To: <4ABCFFA5.9020209@umn.edu>
References: <A4829031-5761-4641-BB69-0D8E3508B624@manchester.ac.uk>
	<4ABCA365.1070108@uk.clara.net> <4ABCF4AB.7060301@umn.edu>
	<20090925165451.GT1508@greenie.muc.de>  <4ABCFFA5.9020209@umn.edu>
Message-ID: <1253910092.2937.1.camel@abehat.net.rm.dk>

On Fri, 2009-09-25 at 12:36 -0500, Ge Moua wrote:
> Gert Doering wrote:
> > PFC3b cannot do MPLS-over-GRE
> 
> what about the 3cxl; we have some of those on hand too.

Same thing, no MPLSoGRE. In almost all practical regards the PFC3C and
PFC3B are the same.

-- 
Peter


From gert at greenie.muc.de  Fri Sep 25 16:47:14 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 25 Sep 2009 22:47:14 +0200
Subject: [c-nsp] EoMPLS v L2TPv3
In-Reply-To: <4ABCFFA5.9020209@umn.edu>
References: <A4829031-5761-4641-BB69-0D8E3508B624@manchester.ac.uk>
	<4ABCA365.1070108@uk.clara.net> <4ABCF4AB.7060301@umn.edu>
	<20090925165451.GT1508@greenie.muc.de> <4ABCFFA5.9020209@umn.edu>
Message-ID: <20090925204714.GV1508@greenie.muc.de>

Hi,

On Fri, Sep 25, 2009 at 12:36:37PM -0500, Ge Moua wrote:
> Gert-
> what about the 3cxl; we have some of those on hand too.

Same.  Difference between 3b and 3c is mainly "MAC address table space",
and xl vs. non-xl is "table size for routing table entries" (TCAM space),
but it's the same EARL.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090925/2518bb1b/attachment.bin>

From rwest at zyedge.com  Sat Sep 26 00:47:41 2009
From: rwest at zyedge.com (Ryan West)
Date: Sat, 26 Sep 2009 00:47:41 -0400
Subject: [c-nsp] Non-Java download option
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F96E2@zy-ex1.zyedge.local>

You asked, now it's here.  You can leverage the download cart to queue up your downloads and get a page with all the URLs.  The main difference is now you have to accept the EULA, whereas with the bookmark or Stig's greasemonkey script, you did not.

-ryan 

From nick at inex.ie  Sat Sep 26 04:32:16 2009
From: nick at inex.ie (Nick Hilliard)
Date: Sat, 26 Sep 2009 09:32:16 +0100
Subject: [c-nsp] Non-Java download option
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F96E2@zy-ex1.zyedge.local>
References: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F96E2@zy-ex1.zyedge.local>
Message-ID: <4ABDD190.2030702@inex.ie>

On 26/09/2009 05:47, Ryan West wrote:
> You asked, now it's here.  You can leverage the download cart to queue
> up your downloads and get a page with all the URLs.  The main difference
> is now you have to accept the EULA, whereas with the bookmark or Stig's
> greasemonkey script, you did not.

http://tools.cisco.com/support/downloads/go/ManualDownload.x

Thank you, Cisco!

Nick

From Stig.Johansen at atea.no  Sat Sep 26 06:51:12 2009
From: Stig.Johansen at atea.no (Stig Johansen)
Date: Sat, 26 Sep 2009 12:51:12 +0200
Subject: [c-nsp] Non-Java download option
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F96E2@zy-ex1.zyedge.local>
References: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F96E2@zy-ex1.zyedge.local>
Message-ID: <5EB9799F396A304686962AFFF740ED0C016DD58F6E@NOOSLEXCH001.adno.local>

Ryan West wrote:
>You asked, now it's here.  You can leverage the download cart 
>to queue up your downloads and get a page with all the URLs.  
>The main difference is now you have to accept the EULA, 
>whereas with the bookmark or Stig's greasemonkey script, 
>you did not.

I guess they took the "subtle" hints after all... I'll be deleting my script now as it has no more use (and won't work anymore anyway).

Good show everyone!

/Stig

From jared at puck.nether.net  Sat Sep 26 08:44:20 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Sat, 26 Sep 2009 08:44:20 -0400
Subject: [c-nsp] Non-Java download option
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F96E2@zy-ex1.zyedge.local>
References: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F96E2@zy-ex1.zyedge.local>
Message-ID: <DFF67F24-EFA1-47E7-8BDE-6E2192431A1B@puck.nether.net>

Everyone should say thanks to Oscar for changing the process to  
accomodate the sp community business needs. You can find his email  
elsewhere in the archive.

Jared Mauch

On Sep 26, 2009, at 12:47 AM, Ryan West <rwest at zyedge.com> wrote:

> You asked, now it's here.  You can leverage the download cart to  
> queue up your downloads and get a page with all the URLs.  The main  
> difference is now you have to accept the EULA, whereas with the  
> bookmark or Stig's greasemonkey script, you did not.
>
> -ryan
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From moua0100 at umn.edu  Sat Sep 26 11:28:11 2009
From: moua0100 at umn.edu (Ge Moua)
Date: Sat, 26 Sep 2009 10:28:11 -0500
Subject: [c-nsp] EoMPLS v L2TPv3
In-Reply-To: <4ABCF4AB.7060301@umn.edu>
References: <A4829031-5761-4641-BB69-0D8E3508B624@manchester.ac.uk>
	<4ABCA365.1070108@uk.clara.net> <4ABCF4AB.7060301@umn.edu>
Message-ID: <4ABE330B.8090702@umn.edu>

David Freeman-
We do have a native MPLS backbone and one of our provider does procide 
MPLS CsC about 24 of our remote sites.
For about 12 of our other sites, the service providers only offer native 
IP services.

Any reasons why you have a distaste for MPLSoGRE?

The Cisco TAC has actually told me they have more expertise and 
experience with MPLSoGRE and has suggested the move away from L2TPv3.

Thanks for your feedback.

Regards,
Ge Moua
University of Minnesota



david.freedman at uk
Sep 25, 2009, 9:56 AM
Post #7 of 10 (18 views)
Permalink
   
Re: EoMPLS v L2TPv3 Remove Highlighting [In reply to]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think the choice is simple.

If you have a "native" MPLS backbone, use EoMPLS.

If you don't, then don't, use L2TPv3, please don't do MPLSoGRE,
it is more trouble than it is worth.

That said, can you not build out a native MPLS network? does your
provider not give you the ability to do this?

Dave.

> David Freedman-
> Do you have a preference of one over the other?  I've been thinking 
> about the option of replacing our L2TPv3 deployment with EoMPLS (ie, 
> Cisco's ATOM model).
>
> We are using Cisco 7203 with NSE engine for L2TPv3 acceleration; but 
> I'm not a big fan of this platform; we have 3bxl-sup720/cat6k at the 
> core that can do MPLS in hardware; I was just thinking of using GRE to 
> encapsulate the MPLS packet over to the spoke sites (thereby bypassing 
> the need to do MPLS end-to-end); this would allow EoMPLS over service 
> providers' native IP infrastructure.
>
> Feedback?
>
>
>
> Regards,
> Ge Moua | Email: moua0100 at umn.edu
>
> Network Design Engineer
> University of Minnesota | Networking & Telecommunications Services
>
>
>
> David Freedman wrote:
>> Wow, this is actually a tricky question, so I'll jot down some points
>> for you to think about from the top of my head (and anybody, please feel
>> free to correct these if they are wrong, they may be out of date)
>>
>> EoMPLS:
>>
>>  - Requires end-to-end MPLS LSP
>>  - Does not support path fragmentation (need wider MTU end-to-end)
>>  - Hardware support good
>>  - OAM available
>>  - Closer ties with MPLS-TE
>>  - some vendors have attachment circuit interworking
>>  - some hardware vendors may not be happy about attachment circuit MTU
>> mismatch
>>
>>
>> L2TPv3:
>>
>>  - Only requires IP (but has some rudimentary security (Cookie))
>>  - "Path" Can be encrypted by IPSEC (this is actually a moot point, even
>> in a world where stuff like draft-raggarwa-mpls-ipsec wasn't
>> implemented, you can still encrypt the payloads of both technologies)
>>  - Not well supported in hardware, lots of restrictions
>>  - interworking support in hardware poor
>>  - lack of proper OAM
>>
>>
>>
>> Dave.
>>
>>
>> Michael Robson wrote:
>>  
>>> What is the added benefit of running an EoMPLS pseudowire across an 
>>> MPLS
>>> cloud over an L2TPv3 tunnel over the same cloud?
>>>
>>>
>>> Michael
>>>     
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>   
>


From gsgranados at comcast.net  Sat Sep 26 11:37:03 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Sat, 26 Sep 2009 08:37:03 -0700
Subject: [c-nsp] Non-Java download option
References: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F96E2@zy-ex1.zyedge.local>
	<DFF67F24-EFA1-47E7-8BDE-6E2192431A1B@puck.nether.net>
Message-ID: <005801ca3ebf$326ed380$bf00a8c0@am.thmulti.com>

Yes and I got another follow up from a specific accessibility group that 
will be looking in to the issue from that angle so I'm also quite pleased. 
Well done C.

----- Original Message ----- 
From: "Jared Mauch" <jared at puck.nether.net>
To: "Ryan West" <rwest at zyedge.com>
Cc: <cisco-nsp at puck.nether.net>
Sent: Saturday, September 26, 2009 5:44 AM
Subject: Re: [c-nsp] Non-Java download option


> Everyone should say thanks to Oscar for changing the process to 
> accomodate the sp community business needs. You can find his email 
> elsewhere in the archive.
>
> Jared Mauch
>
> On Sep 26, 2009, at 12:47 AM, Ryan West <rwest at zyedge.com> wrote:
>
>> You asked, now it's here.  You can leverage the download cart to  queue 
>> up your downloads and get a page with all the URLs.  The main  difference 
>> is now you have to accept the EULA, whereas with the  bookmark or Stig's 
>> greasemonkey script, you did not.
>>
>> -ryan
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From david.freedman at uk.clara.net  Sat Sep 26 11:32:15 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Sat, 26 Sep 2009 16:32:15 +0100
Subject: [c-nsp] EoMPLS v L2TPv3
References: <A4829031-5761-4641-BB69-0D8E3508B624@manchester.ac.uk>
	<4ABCA365.1070108@uk.clara.net> <4ABCF4AB.7060301@umn.edu>
	<4ABE330B.8090702@umn.edu>
Message-ID: <7B8B0D6F623C3A40A0D0A80A66756E2B2C2F0D@EXVS01.claranet.local>

Well, if you are TAC supported, go for it, I don't like it because it is layering another control network over IP which adds more to the list of things to troubleshoot. You also have to watch your MTU.

Dave.


------------------------------------------------
David Freedman
Group Network Engineering 
Claranet Limited
http://www.clara.net



-----Original Message-----
From: Ge Moua [mailto:moua0100 at umn.edu]
Sent: Sat 9/26/2009 16:28
To: moua0100 at umn.edu
Cc: David Freedman; Michael Robson; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] EoMPLS v L2TPv3
 
David Freeman-
We do have a native MPLS backbone and one of our provider does procide 
MPLS CsC about 24 of our remote sites.
For about 12 of our other sites, the service providers only offer native 
IP services.

Any reasons why you have a distaste for MPLSoGRE?

The Cisco TAC has actually told me they have more expertise and 
experience with MPLSoGRE and has suggested the move away from L2TPv3.

Thanks for your feedback.

Regards,
Ge Moua
University of Minnesota



david.freedman at uk
Sep 25, 2009, 9:56 AM
Post #7 of 10 (18 views)
Permalink
   
Re: EoMPLS v L2TPv3 Remove Highlighting [In reply to]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think the choice is simple.

If you have a "native" MPLS backbone, use EoMPLS.

If you don't, then don't, use L2TPv3, please don't do MPLSoGRE,
it is more trouble than it is worth.

That said, can you not build out a native MPLS network? does your
provider not give you the ability to do this?

Dave.

> David Freedman-
> Do you have a preference of one over the other?  I've been thinking 
> about the option of replacing our L2TPv3 deployment with EoMPLS (ie, 
> Cisco's ATOM model).
>
> We are using Cisco 7203 with NSE engine for L2TPv3 acceleration; but 
> I'm not a big fan of this platform; we have 3bxl-sup720/cat6k at the 
> core that can do MPLS in hardware; I was just thinking of using GRE to 
> encapsulate the MPLS packet over to the spoke sites (thereby bypassing 
> the need to do MPLS end-to-end); this would allow EoMPLS over service 
> providers' native IP infrastructure.
>
> Feedback?
>
>
>
> Regards,
> Ge Moua | Email: moua0100 at umn.edu
>
> Network Design Engineer
> University of Minnesota | Networking & Telecommunications Services
>
>
>
> David Freedman wrote:
>> Wow, this is actually a tricky question, so I'll jot down some points
>> for you to think about from the top of my head (and anybody, please feel
>> free to correct these if they are wrong, they may be out of date)
>>
>> EoMPLS:
>>
>>  - Requires end-to-end MPLS LSP
>>  - Does not support path fragmentation (need wider MTU end-to-end)
>>  - Hardware support good
>>  - OAM available
>>  - Closer ties with MPLS-TE
>>  - some vendors have attachment circuit interworking
>>  - some hardware vendors may not be happy about attachment circuit MTU
>> mismatch
>>
>>
>> L2TPv3:
>>
>>  - Only requires IP (but has some rudimentary security (Cookie))
>>  - "Path" Can be encrypted by IPSEC (this is actually a moot point, even
>> in a world where stuff like draft-raggarwa-mpls-ipsec wasn't
>> implemented, you can still encrypt the payloads of both technologies)
>>  - Not well supported in hardware, lots of restrictions
>>  - interworking support in hardware poor
>>  - lack of proper OAM
>>
>>
>>
>> Dave.
>>
>>
>> Michael Robson wrote:
>>  
>>> What is the added benefit of running an EoMPLS pseudowire across an 
>>> MPLS
>>> cloud over an L2TPv3 tunnel over the same cloud?
>>>
>>>
>>> Michael
>>>     
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>   
>



From eng_mssk at hotmail.com  Sun Sep 27 06:45:39 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Sun, 27 Sep 2009 13:45:39 +0300
Subject: [c-nsp] Hacking
Message-ID: <BLU102-W25D30127E337B811224114FAD70@phx.gbl>


hey all

can i know from the log or using any other method if the router was hacked ??
 		 	   		  
_________________________________________________________________
Show them the way! Add maps and directions to your party invites. 
http://www.microsoft.com/windows/windowslive/products/events.aspx

From dr at cluenet.de  Sun Sep 27 07:52:07 2009
From: dr at cluenet.de (Daniel Roesen)
Date: Sun, 27 Sep 2009 13:52:07 +0200
Subject: [c-nsp] Ethernet Preamble and FCS on EoMPLS
In-Reply-To: <20090925175023.GA13601@fart>
References: <6cf7fb160909250933u4e80d5aak762ffdab59e64b8c@mail.gmail.com>
	<20090925175023.GA13601@fart>
Message-ID: <20090927115207.GA21807@srv03.cluenet.de>

On Fri, Sep 25, 2009 at 07:50:23PM +0200, Reinhold Fischer wrote:
> What would be the benefit of transporting the Ethernet preamble?

Transparently transporting OAM done within the preamble?


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0

From alex at digriz.org.uk  Sun Sep 27 07:31:17 2009
From: alex at digriz.org.uk (Alexander Clouter)
Date: Sun, 27 Sep 2009 12:31:17 +0100
Subject: [c-nsp] Hacking
References: <BLU102-W25D30127E337B811224114FAD70@phx.gbl>
Message-ID: <51v3p6-7he.ln1@chipmunk.wormnet.eu>

Mohammad Khalil <eng_mssk at hotmail.com> wrote:
> 
> can i know from the log or using any other method if the router was hacked ??
>                                          
When RANCID collects (or fails to collect) the configuration file off 
your router every day (or hour), it will compare it to the previous run 
and email you the differences.  Those differences will show you when 
someone caught you with your pants down...or when someone fat fingered 
an amendment.

Cheers

-- 
Alexander Clouter
.sigmonster says: semper en excretus


From graham at g-rock.net  Sun Sep 27 08:30:24 2009
From: graham at g-rock.net (Graham Wooden)
Date: Sun, 27 Sep 2009 07:30:24 -0500
Subject: [c-nsp] Hacking
In-Reply-To: <BLU102-W25D30127E337B811224114FAD70@phx.gbl>
Message-ID: <C6E4C510.AD80%graham@g-rock.net>

Well, if they didn't clear your logging buffer, you will see an entry like
this in your log on the router if they went into config mode:

    Sep 23 12:25:00.603: %SYS-5-CONFIG_I: Configured from console by
log_in_username on vty0 (src IP addy)

So, it will show you the username they logged in as and from what IP.

HTH,

-graham


On 9/27/09 5:45 AM, "Mohammad Khalil" <eng_mssk at hotmail.com> wrote:

> 
> hey all
> 
> can i know from the log or using any other method if the router was hacked ??
>  
> _________________________________________________________________
> Show them the way! Add maps and directions to your party invites.
> http://www.microsoft.com/windows/windowslive/products/events.aspx
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



From jared at puck.nether.net  Sun Sep 27 09:01:00 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Sun, 27 Sep 2009 09:01:00 -0400
Subject: [c-nsp] Hacking
In-Reply-To: <C6E4C510.AD80%graham@g-rock.net>
References: <C6E4C510.AD80%graham@g-rock.net>
Message-ID: <974C8994-FBF3-4F75-9274-131FB5FEB1A0@puck.nether.net>

You can syslog these messages remotely as well.

there are numerous ways to create a chain of events that will allow  
someone to hide their tracks, the best methods are to null route the  
ip of the tacacs, radius or logging server, clearing logs, etc.

	- Jared

On Sep 27, 2009, at 8:30 AM, Graham Wooden wrote:

> Well, if they didn't clear your logging buffer, you will see an  
> entry like
> this in your log on the router if they went into config mode:
>
>    Sep 23 12:25:00.603: %SYS-5-CONFIG_I: Configured from console by
> log_in_username on vty0 (src IP addy)
>
> So, it will show you the username they logged in as and from what IP.
>
> HTH,
>
> -graham
>
>
> On 9/27/09 5:45 AM, "Mohammad Khalil" <eng_mssk at hotmail.com> wrote:
>
>>
>> hey all
>>
>> can i know from the log or using any other method if the router was  
>> hacked ??
>>
>> _________________________________________________________________
>> Show them the way! Add maps and directions to your party invites.
>> http://www.microsoft.com/windows/windowslive/products/events.aspx
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From david.freedman at uk.clara.net  Sun Sep 27 10:27:45 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Sun, 27 Sep 2009 15:27:45 +0100
Subject: [c-nsp] Another bughunt, this time VRF PBR
Message-ID: <7B8B0D6F623C3A40A0D0A80A66756E2B2C2F13@EXVS01.claranet.local>

wonder if anybody has come across this before,

in 12.4(15)T, configuring a virtual-access per-user such:

        Framed-IP-Address = 10.0.0.1,
        Cisco-AVPAIR += "lcp:interface-config=ip policy route-map TEST\nip vrf receive TEST\n",
        Cisco-AVPAIR += "ip:route=vrf TEST 192.168.100.0 255.255.255.0 10.0.0.1"

The policy map simply uses an access list to match source 192.168.100.0/24 and set vrf TEST.


But results in the following vrf CEF table:

Prefix              Next Hop             Interface
0.0.0.0/0           drop                 Null0 (default route handler entry)
0.0.0.0/32          receive
10.0.0.1/32         receive
192.168.100.0/24    10.0.0.1 (?)
224.0.0.0/4         drop
224.0.0.0/24        receive
255.255.255.255/32  receive

#sh ip cef vrf TEST 192.168.100.0 internal
192.168.100.0/24, version 32, epoch 0
0 packets, 0 bytes
  tag information set
    local tag: assigned-when-resolved-later
  Flow: Origin AS 0, Peer AS 0, mask 24
  via 10.0.0.1, 0 dependencies, recursive
    unresolved
  refcount 5


The lack of being able to resolve the per-user static results in a label being assigned
and distributed to other PE routers, but this label not being retained internally!
(so traffic is dropped on ingress)

This is obviously broken but can't find the bugID, closest I can find is CSCse37042
This also does not appear to be a feature restriction as far as I can tell from the documentation.

configuring a manual static to the next-hop also results in this odd behaviour.

Any help appreciated.

TIA

------------------------------------------------
David Freedman
Group Network Engineering 
Claranet Limited
http://www.clara.net


From eng_mssk at hotmail.com  Sun Sep 27 12:52:03 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Sun, 27 Sep 2009 19:52:03 +0300
Subject: [c-nsp] Power Issue
Message-ID: <BLU102-W6089A9E53FF96DFA6F7CAFAD70@phx.gbl>


We have Cisco device
cisco ME-C6524GT-8S (R7000) processor (revision 1.3) with 458752K/65536K bytes of memory.
Processor board ID CAT1209C0AV
R7000 CPU at 300Mhz, Implementation 0x27, Rev 3.3, 256KB L2, 1024KB L3 Cache
Last reset from power-on
SuperLAT software (copyright 1990 by Meridian Technology Corp).
X.25 software, Version 3.0.0.
Bridging software.
TN3270 Emulation software.
4 Virtual Ethernet/IEEE 802.3 interfaces
32 Gigabit Ethernet/IEEE 802.3 interfaces
1915K bytes of non-volatile configuration memory.

65536K bytes of Flash internal SIMM (Sector size 256K).
Configuration register is 0x2102

now the issue is that we have in each site a device like the mentioned and a WiMAX RAS , all is functoning on DC power
now the issue is that we are experiencing Traffic down (coz of RAS down) even that no interface on the switch went down nor something mentioned in the switch 
i want to know where can i resolve this issue 
can i monitor the power ?? i tried to use snmpwalk but didnt get any result , is that due to an IOS version ??

Thanks
 		 	   		  
_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

From zivl at gilat.net  Sun Sep 27 13:15:38 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Sun, 27 Sep 2009 19:15:38 +0200
Subject: [c-nsp] Which IP's belong to AS1234?
In-Reply-To: <4ABD0215.20407@howells.me>
References: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>
	<4ABC718E.90908@thingy.com>
	<56F211C5E3F24F47B103EA1B253822BE044AAC99@vic-cr-ex1.staff.netspace.net.au>
	<4ABD0215.20407@howells.me>
Message-ID: <EC993E87D960A541A66BF21D62AA42A6232C85C80B@exch2k7.gilat.local>

I use CIDR Reports, great site with useful stuff
http://www.cidr-report.org/cgi-bin/as-report?as=AS1234

Put whatever AS you want in the end of the link
HTH
Ziv


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Alex Howells
Sent: Friday, September 25, 2009 8:47 PM
To: Andy Saykao
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Which IP's belong to AS1234?

Andy Saykao wrote:
> This is why I needed to know what IP blocks belong to AS1234, so I could
> find out how much traffic was actually coming from AS1234 on our
> Internet link.

What you actually want is Netflow (or JFlow, sFlow, etc) with a suitably
smart collector, which will provide you with all of this information and
more so that you can make informed peering decisions.

HTH,
Alex
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************




 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************




From p.mayers at imperial.ac.uk  Sun Sep 27 13:56:11 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Sun, 27 Sep 2009 18:56:11 +0100
Subject: [c-nsp] QOS mismatch for channel ports ??
In-Reply-To: <C3176BA2-1504-4407-A468-ED92CC7EB133@Princeton.EDU>
References: <E564318C-4A6D-4B12-BE9A-0CB114710A9B@princeton.edu>
	<1253890787.25869.15.camel@empacher.cns.ufl.edu>
	<C3176BA2-1504-4407-A468-ED92CC7EB133@Princeton.EDU>
Message-ID: <20090927175611.GB3555@wildfire.net.ic.ac.uk>

On Fri, Sep 25, 2009 at 04:41:01PM +0100, Jeff Fitzwater wrote:
>That command is not available on 12.2SXI but I see that I could just  
>disable QOS per PORT.

It's a per-interface command, not a global command, and it's definitely 
available under SXI because we're using it.

i.e.

int Po1
  no mls qos channel-consistency

From panocisco77 at gmail.com  Sun Sep 27 14:49:49 2009
From: panocisco77 at gmail.com (Renelson Panosky)
Date: Sun, 27 Sep 2009 14:49:49 -0400
Subject: [c-nsp] 6509-E with sup720
Message-ID: <16e2ac180909271149y5ad1a013w7d32906571dae63a@mail.gmail.com>

Everytime i power this switch i am getting this error Autoboot: failed, BOOT
string is empty and i can't remember the code to bypass it can anybody help
me with this?

From aaron at wsc.ma.edu  Sun Sep 27 15:05:57 2009
From: aaron at wsc.ma.edu (Childs, Aaron)
Date: Sun, 27 Sep 2009 15:05:57 -0400
Subject: [c-nsp] 6509-E with sup720
In-Reply-To: <16e2ac180909271149y5ad1a013w7d32906571dae63a@mail.gmail.com>
References: <16e2ac180909271149y5ad1a013w7d32906571dae63a@mail.gmail.com>
Message-ID: <3760B7E1B344364AA0384B231FE7BA69126754176F@ex-be1.ads.wsc.ma.edu>

Try  boot [device]:[image file name]

-----------
Aaron Childs
Assistant Director, Networking
Westfield State College
http://www.wsc.ma.edu/it/
________________________________________
From: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net] On Behalf Of Renelson Panosky [panocisco77 at gmail.com]
Sent: Sunday, September 27, 2009 2:49 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] 6509-E with sup720

Everytime i power this switch i am getting this error Autoboot: failed, BOOT
string is empty and i can't remember the code to bypass it can anybody help
me with this?
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From dcp at dcptech.com  Sun Sep 27 15:12:08 2009
From: dcp at dcptech.com (David Prall)
Date: Sun, 27 Sep 2009 15:12:08 -0400
Subject: [c-nsp] 6509-E with sup720
In-Reply-To: <16e2ac180909271149y5ad1a013w7d32906571dae63a@mail.gmail.com>
References: <16e2ac180909271149y5ad1a013w7d32906571dae63a@mail.gmail.com>
Message-ID: <006a01ca3fa6$7b0274c0$71075e40$@com>

Is it dumping to rommon. If so just boot <imagelocation>:<imagename>

Most likely have a corrupt config register on the switch processor.
	Sh boot ! for the RP
	Remote command switch sh boot ! for the SP

Conf t
Config-register 0x2102
End

Now confirm that they are correct on both the RP and SP. I think if you have
too many boot command lines in the config, the chance of the SP becoming
corrupt is higher.

David

--
http://dcp.dcptech.com
 

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Renelson Panosky
> Sent: Sunday, September 27, 2009 2:50 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] 6509-E with sup720
> 
> Everytime i power this switch i am getting this error Autoboot: failed,
> BOOT
> string is empty and i can't remember the code to bypass it can anybody
> help
> me with this?
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From justin at justinshore.com  Sun Sep 27 23:06:00 2009
From: justin at justinshore.com (Justin Shore)
Date: Sun, 27 Sep 2009 22:06:00 -0500
Subject: [c-nsp] Another bughunt, this time VRF PBR
In-Reply-To: <7B8B0D6F623C3A40A0D0A80A66756E2B2C2F13@EXVS01.claranet.local>
References: <7B8B0D6F623C3A40A0D0A80A66756E2B2C2F13@EXVS01.claranet.local>
Message-ID: <4AC02818.1020104@justinshore.com>

David Freedman wrote:
> wonder if anybody has come across this before,
> 
> in 12.4(15)T, configuring a virtual-access per-user such:

I hate to suggest the obvious but since there are so many bugs in 
12.4(15)T have you considered bumping that to the latest minor rev?  I 
think they're up to T7 or T8 now (must have been some bug list).

Justin



From justin at justinshore.com  Sun Sep 27 23:19:59 2009
From: justin at justinshore.com (Justin Shore)
Date: Sun, 27 Sep 2009 22:19:59 -0500
Subject: [c-nsp] Power Issue
In-Reply-To: <BLU102-W6089A9E53FF96DFA6F7CAFAD70@phx.gbl>
References: <BLU102-W6089A9E53FF96DFA6F7CAFAD70@phx.gbl>
Message-ID: <4AC02B5F.9020600@justinshore.com>

Mohammad Khalil wrote:
> We have Cisco device
> cisco ME-C6524GT-8S (R7000) processor (revision 1.3) with 458752K/65536K bytes of memory.
> 
> now the issue is that we have in each site a device like the mentioned and a WiMAX RAS , all is functoning on DC power
> now the issue is that we are experiencing Traffic down (coz of RAS down) even that no interface on the switch went down nor something mentioned in the switch 
> i want to know where can i resolve this issue 
> can i monitor the power ?? i tried to use snmpwalk but didnt get any result , is that due to an IOS version ??

  which keeps the ME6524 If I understand your query correctly, your RAS 
is going down and the ME6524 isn't getting a link down.  Is that 
correct?  When you say that the RAS is going down are you saying that 
it's powering down and that there should be a link down on all 
interfaces connected to it, or are you saying that internally the RAS is 
not passing traffic for whatever reason (config error for example) but 
its Ethernet links are staying up which lets the ME6524 keep sending 
traffic towards the RAS?  If the links aren't going operationally down 
then the ME6524 really isn't to blame if it keeps on sending traffic out 
those links.

Is the connection to the RAS a routed connection (interface) or a 
switchport?  If the WiMax is used as a backhaul link between 2 sites and 
the interfaces of the routers on each end are routed interfaces then you 
could use BFD to ensure that L3 connectivity is up across the path.  If 
it's a switchport on each end but otherwise has the same network 
scenario (backhaul, not CE-facing) then you might be able to accomplish 
something similar with UDLD.  You could probably get fancy with IP SLA 
and some static routes to create some similar as well.  Be forewarned, 
if you're still using the initial code release for the ME6524 (12.2(ZU)) 
and you implement BFD on a SVI then you will lose that working feature 
when you upgrade to SXH.  You can search the list archives for numerous 
posts regarding that change.

If I've completely misread your query and you are in fact asking about 
DC power in the ME6524 and are trying to figure out how to query it via 
SNMP to see if a power supply has failed, then I have no idea.  My 
ME6524s are also DC-powered.  Do you have 2 separate DC buses connected 
to each ME6524?  Is the RAS on one of the same buses?  Does it have dual 
power supplies with dual buses connected to it as well?

Justin


From mtinka at globaltransit.net  Mon Sep 28 03:12:33 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 28 Sep 2009 15:12:33 +0800
Subject: [c-nsp] OSPF to ISIS migartion
In-Reply-To: <20090924215719.GA22353@lboro.ac.uk>
References: <8bb137f40909230050vce3c824mc31113a20bfde129@mail.gmail.com>
	<4b8f66d70909241353q5bddc874i6678bf37d706ba9d@mail.gmail.com>
	<20090924215719.GA22353@lboro.ac.uk>
Message-ID: <200909281512.34692.mtinka@globaltransit.net>

On Friday 25 September 2009 05:57:19 am Alan Buxey wrote:

> I'd agree. plan in advance. prepare the config.
> enable and configure the ISIS, ensure that everything is
> using it, lower the OSPF priority so ISIS takes over.
> check everything is all okay. turn OSPF off. done.

I probably would also submit that since IPv6 is getting more 
real with each passing day, future-proof your IS-IS 
deployment and add Multi-Topology IS-IS when you deploy.

MT will be very helpful when you start turning up those IPv6 
links, assuming you'll be going for a dual-stack deployment.

Cheers,

Mark. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090928/8690363a/attachment.bin>

From mtinka at globaltransit.net  Mon Sep 28 03:32:12 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 28 Sep 2009 15:32:12 +0800
Subject: [c-nsp] Inter-AS L2VPN redundancy, option B (Ruzhanskaya Olga)
In-Reply-To: <E1MqiYP-0005at-00.frosya84-mail-ru@f179.mail.ru>
References: <6b300f5d0909230512o17b8dbd6t6e64554a8ed8e33b@mail.gmail.com>
	<E1MqiYP-0005at-00.frosya84-mail-ru@f179.mail.ru>
Message-ID: <200909281532.19191.mtinka@globaltransit.net>

On Thursday 24 September 2009 03:15:49 pm ????? ????????? 
wrote:

> Thank You for book,
> but approach proposed in it is for redundancy inside 1
> AS, not between 2 AS. I've seen it on cisco.com before..

Funny you should mention this - I was just talking to our 
account team about options for EoMPLS NNI's from an inter-op 
point of view.

Basically, L2VPN Pseudowire Switching and Back-to-Back 
VLAN's are a single point of failure. You may add redundancy 
by replicating NNI sessions, but this may not be scalable 
from a management perspective.

You may also consider the options provided by Phil re: 
Option C. I can't say we've looked at that yet.

But yes, if Cisco supported Option B BGP-style, that would 
have been possible. But they do not.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090928/2f385ea3/attachment-0001.bin>

From andreir at gmail.com  Mon Sep 28 04:20:01 2009
From: andreir at gmail.com (Andrei Radu)
Date: Mon, 28 Sep 2009 11:20:01 +0300
Subject: [c-nsp] 7600 / SRC4 shutting down it's interfaces
Message-ID: <74206b240909280120y3817665fi12ba690f6e82365@mail.gmail.com>

Hello everybody,

 Yesterday we did a network wide upgrade on our 7600 routers from SRB4
to SRC4. After the upgrade we were hit pretty hard by one of the
weirdest 7600 behaviours ever.

 Between a pair of 7600 routers, let's say R1 and R2 (both with
SUP720-3BXL and 6704-10GE with DFC3BXL or DFC3CXL line-cards) we have
5 10GE links configured for IGP equal-cost load-balancing (the IGP
being OSPF in our case). After about 3-4 hours from the upgrade R1
started shutting down one of it's interfaces from the 5 10GE
interfaces group, the bringing it back up (it was the Te11/1
interface). When I say shutting down I mean that in the logs appeared
"changed state to administratively down" and in the
running-configuration the "shutdown" command appeared under that
interface and after a couple of seconds the "shutdown" command
disappeared. I am 100% sure that no person was issuing any commands on
R1 (we have even disabled SNMP just to make sure).

 We use a mixture of Cisco and non-Cisco optical modules so first we
tried exchanging the XENPAKs with new/original ones and replacing the
fiber optic patches. Then we tried moving the configuration to a new
port (Te10/1, on a different line-card) and the problem persisted.
After a couple hours the situation deteriorated with overruns on some
interfaces and packet loss for traffic transiting R1. After we have
rebooted module 10 (so the second line-card with the problem, not the
first one) the problem cleared.

 We have opened a TAC case and we are waiting for some feedback, in
the mean time has anyone else encountered this behaviour ? The only
thing I could find is CSCsv17989 (interface in SIP200 show "admin
down" when it is physical down) but according to the bug description
that is only a cosmetic problem.

 Best regards,
-- 
Andrei

"2+2=5, for extremely large values of 2 !"

From frosya84 at mail.ru  Mon Sep 28 04:26:49 2009
From: frosya84 at mail.ru (=?koi8-r?Q?=EF=CC=D8=C7=C1_=F2=D5=D6=C1=CE=D3=CB=C1=D1?=)
Date: Mon, 28 Sep 2009 12:26:49 +0400
Subject: [c-nsp]
	=?koi8-r?b?SW50ZXItQVMgTDJWUE4gcmVkdW5kYW5jeSwgb3B0aW9u?=
	=?koi8-r?b?IEIgKFJ1emhhbnNrYXlhIE9sZ2Ep?=
In-Reply-To: <200909281532.19191.mtinka@globaltransit.net>
References: <200909281532.19191.mtinka@globaltransit.net>
Message-ID: <E1MsBZJ-0007Rk-00.frosya84-mail-ru@f250.mail.ru>

Thank You for reply.

> Basically, L2VPN Pseudowire Switching and Back-to-Back 
> VLAN's are a single point of failure. You may add redundancy 
> by replicating NNI sessions, but this may not be scalable 
> from a management perspective.
I just want to add little comment this statement (maybe I'm wrong..). 
Talking about the Cisco equipment, for option B we cannot build a redundant scheme even replicating NNI;
because point-to-point VFIs have not ability to check, is the neighbor down.
But for back-to-back we still can use redundant links (maybe there will be questions for intervendor compatibility, Phil re:).

> Option C. I can't say we've looked at that yet.
The main question is security - each AS will have reachability to all the internal next-hops in the other AS. Otherwise, this is the most scalable and flexible option.

Best regards,
Olga




From alex at erus.co.uk  Mon Sep 28 04:28:24 2009
From: alex at erus.co.uk (Alex Pimperton)
Date: Mon, 28 Sep 2009 09:28:24 +0100
Subject: [c-nsp] HWIC-1ADSL-M
In-Reply-To: <4d6de31b0909220452m14ad62e7q8cb3d7fbd077c849@mail.gmail.com>
References: <4d6de31b0909220452m14ad62e7q8cb3d7fbd077c849@mail.gmail.com>
Message-ID: <000001ca4015$a5d28a90$f1779fb0$@co.uk>

> This is an interesting one. I've used 877-M and 1801-M with Be/O2 and
> don't have a problem on Annex M.
> 
> On Friday I tried both with a Tiscali (via Griffin) service and
> couldn't get it to sync at Annex M. When they re-graded it to remove
> the Annex M it suddenly synced, but now we are seeing pretty bad QoS,
> mostly packet loss. Doesn't seem to be line (SNR) or bandwidth
> related, but there is significant error correction activity on the
> downstream link which I find strange.
> 
> I have heard rumours about Cisco kit not liking the Tiscali DSLAMs but
> can't find anything to back this up.

Thanks Richard,

I've also heard rumours (http://piersdaniell.com/wordpress/?p=102) but as
it's the blog of a chap who works for the competition I'll take it with a
grain of salt!

I actually wanted to use Nildram but after about 5 goes at getting
compatibility info out of Nildram tech support I gave up.

Looks like it'll be Be as various people have confirmed that working.

Cheers for the help.

Alex


-- 
This message has been scanned for viruses and
dangerous content by AxTech, and is
believed to be clean.


From mtinka at globaltransit.net  Mon Sep 28 05:39:43 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 28 Sep 2009 17:39:43 +0800
Subject: [c-nsp] modular code for the 6500
In-Reply-To: <FDFA03A8DE9E491A9073052245F6C7A3@flamdt01>
References: <836bf1f90909240915l5ee5ba15g73f87f3bbcce53bc@mail.gmail.com>
	<FDFA03A8DE9E491A9073052245F6C7A3@flamdt01>
Message-ID: <200909281739.44104.mtinka@globaltransit.net>

On Friday 25 September 2009 11:05:43 am Tony Varriale wrote:

> I'm not even recommending it until it gets much further
> along and gets some serious field experience.

Being that 'c-nsp' might be considered a fairly general 
representation of the "field", and it appears Modular IOS is 
not gaining many (new) friends here in the last several 
years, it would be interesting to see where this goes... :-)

As Dale has already mentioned, adoption may be more 
successful if it's integrated into the platform, e.g., IOS 
XR + CRS-1/ASR9000, e.t.c., and/or Cisco have no more 
financial incentive to maintain the monolithic releases.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090928/f03b195e/attachment.bin>

From mtinka at globaltransit.net  Mon Sep 28 05:43:20 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 28 Sep 2009 17:43:20 +0800
Subject: [c-nsp] Pile on the 6509 noob
In-Reply-To: <C6E1121E.4FD6%cisco@peakpeak.com>
References: <C6E1121E.4FD6%cisco@peakpeak.com>
Message-ID: <200909281743.21346.mtinka@globaltransit.net>

On Friday 25 September 2009 02:10:06 am CJ wrote:

> Finally, if I solved this issue, I'm wondering about the
> relative wisdom of using the FlexWAN card.  I want to put
> a PA-2DS3 in it and also a PA-MC-T3. Is this an
> enlightened practice?

We've always been against trying to turn an Ethernet box 
into a TDM/SONET/SDH device, as it's never cheap considering 
how much bandwidth you're losing per slot relative to the 
investment in adding non-Ethernet support as well as the 
kind of bandwidth you'd be getting out of it.

It's the same thing Juniper did with their MX-FPC carrier 
cards, adding support for SONET/SDH PIC's in the MX-series 
routers. I'd still find it cheaper to buy a smaller box that 
talks Ethernet and non-Ethernet fairly equally from an 
overall cost/benefit-perspective.

But that's just us :-)... I'm sure a number of networks in 
the wild find this feature quite useful, which is why the 
vendors continue to find ways to provide support for it.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090928/07a476f0/attachment.bin>

From gert at greenie.muc.de  Mon Sep 28 05:58:15 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 28 Sep 2009 11:58:15 +0200
Subject: [c-nsp] modular code for the 6500
In-Reply-To: <200909281739.44104.mtinka@globaltransit.net>
References: <836bf1f90909240915l5ee5ba15g73f87f3bbcce53bc@mail.gmail.com>
	<FDFA03A8DE9E491A9073052245F6C7A3@flamdt01>
	<200909281739.44104.mtinka@globaltransit.net>
Message-ID: <20090928095815.GX1508@greenie.muc.de>

Hi,

On Mon, Sep 28, 2009 at 05:39:43PM +0800, Mark Tinka wrote:
> On Friday 25 September 2009 11:05:43 am Tony Varriale wrote:
> 
> > I'm not even recommending it until it gets much further
> > along and gets some serious field experience.
> 
> Being that 'c-nsp' might be considered a fairly general 
> representation of the "field", and it appears Modular IOS is 
> not gaining many (new) friends here in the last several 
> years, it would be interesting to see where this goes... :-)

Well, as far as I understand, SXI2 is about the first release that
is mature enough to really use modular.  Finally.

So we'll do a round of detailed testing "soonish", and then decide
what to put on our production routers.

What I saw in the last PSIRT advisories made me quite happy - they did
indeed release patches for modular IOS, so it's starting to live up to
the promises.

Now... modular 12.5 would be very nice.  With features coming first to
modular, and only later on to legacy monolithic IOS.  Or so.  And a 
company that demonstrates that they stand behind this infrastructure 
change (which is currently not very obvious...).

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090928/72a7f8ec/attachment.bin>

From dean at eatworms.org.uk  Mon Sep 28 07:58:12 2009
From: dean at eatworms.org.uk (Dean Smith)
Date: Mon, 28 Sep 2009 12:58:12 +0100
Subject: [c-nsp] HWIC-1ADSL-M
References: <4d6de31b0909220452m14ad62e7q8cb3d7fbd077c849@mail.gmail.com>
	<000001ca4015$a5d28a90$f1779fb0$@co.uk>
Message-ID: <885EC2706E264CC992EE7195BDE4142A@experienbd1776>

Ofcom tweaked the Annex M mask (the range of frequencies used for the 
upstream) for the UK from the international standard. To be compliant with 
the "Access Network Frequency Plan" (or "how you use a copper line in the 
UK") the UK specific frequency mask should be used.

As (now) stated in the Cisco dats sheets they dont support the UK mask. 
Though that data sheet amendment is relatively new.

I would therefore question the providers of LLU services that have an Annex 
M service working with current Cisco hardware whether their exchange 
equipment also implements the ofcom ANFP with regards to Annex M.

I beleive code enhancements from Cisco to be UK compliant are coming.

http://www.niccstandards.org.uk/files/current/nd1405_2005_08.pdf?type=pdf

Section 6.6 & 6.8 refer to the above issue.

Dean

----- Original Message ----- 
From: "Alex Pimperton" <alex at erus.co.uk>
To: <cisco-nsp at puck.nether.net>
Sent: Monday, September 28, 2009 9:28 AM
Subject: Re: [c-nsp] HWIC-1ADSL-M


>> This is an interesting one. I've used 877-M and 1801-M with Be/O2 and
>> don't have a problem on Annex M.
>>
>> On Friday I tried both with a Tiscali (via Griffin) service and
>> couldn't get it to sync at Annex M. When they re-graded it to remove
>> the Annex M it suddenly synced, but now we are seeing pretty bad QoS,
>> mostly packet loss. Doesn't seem to be line (SNR) or bandwidth
>> related, but there is significant error correction activity on the
>> downstream link which I find strange.
>>
>> I have heard rumours about Cisco kit not liking the Tiscali DSLAMs but
>> can't find anything to back this up.
>
> Thanks Richard,
>
> I've also heard rumours (http://piersdaniell.com/wordpress/?p=102) but as
> it's the blog of a chap who works for the competition I'll take it with a
> grain of salt!
>
> I actually wanted to use Nildram but after about 5 goes at getting
> compatibility info out of Nildram tech support I gave up.
>
> Looks like it'll be Be as various people have confirmed that working.
>
> Cheers for the help.
>
> Alex
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by AxTech, and is
> believed to be clean.
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> __________ NOD32 4462 (20090927) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
> 


From david.freedman at uk.clara.net  Mon Sep 28 08:38:46 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Mon, 28 Sep 2009 13:38:46 +0100
Subject: [c-nsp] Another bughunt, this time VRF PBR
References: <7B8B0D6F623C3A40A0D0A80A66756E2B2C2F13@EXVS01.claranet.local>
	<4AC02818.1020104@justinshore.com>
Message-ID: <7B8B0D6F623C3A40A0D0A80A66756E2B2C2F18@EXVS01.claranet.local>

Yes, I woul absolutely love to, believe me :)
Need to make sure nobody steps in at this point and claims that this is unsupported, if it is then am happy
to move it to SR and away from 12.4(T) completely.

------------------------------------------------
David Freedman
Group Network Engineering 
Claranet Limited
http://www.clara.net



-----Original Message-----
From: Justin Shore [mailto:justin at justinshore.com]
Sent: Mon 9/28/2009 04:06
To: David Freedman
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Another bughunt, this time VRF PBR
 
David Freedman wrote:
> wonder if anybody has come across this before,
> 
> in 12.4(15)T, configuring a virtual-access per-user such:

I hate to suggest the obvious but since there are so many bugs in 
12.4(15)T have you considered bumping that to the latest minor rev?  I 
think they're up to T7 or T8 now (must have been some bug list).

Justin




From rodunn at cisco.com  Mon Sep 28 09:55:03 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Mon, 28 Sep 2009 09:55:03 -0400
Subject: [c-nsp] Non-Java download option
In-Reply-To: <DFF67F24-EFA1-47E7-8BDE-6E2192431A1B@puck.nether.net>
References: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F96E2@zy-ex1.zyedge.local>
	<DFF67F24-EFA1-47E7-8BDE-6E2192431A1B@puck.nether.net>
Message-ID: <4AC0C037.5050005@cisco.com>

Glad to know some positive progress was made.

Thanks to those that took the time to provide helpful feedback.

Rodney



Jared Mauch wrote:
> Everyone should say thanks to Oscar for changing the process to 
> accomodate the sp community business needs. You can find his email 
> elsewhere in the archive.
> 
> Jared Mauch
> 
> On Sep 26, 2009, at 12:47 AM, Ryan West <rwest at zyedge.com> wrote:
> 
>> You asked, now it's here.  You can leverage the download cart to queue 
>> up your downloads and get a page with all the URLs.  The main 
>> difference is now you have to accept the EULA, whereas with the 
>> bookmark or Stig's greasemonkey script, you did not.
>>
>> -ryan
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From mailinglists at uebi.net  Mon Sep 28 10:50:55 2009
From: mailinglists at uebi.net (Bernd)
Date: Mon, 28 Sep 2009 16:50:55 +0200
Subject: [c-nsp] Config question for a strange design
In-Reply-To: <885EC2706E264CC992EE7195BDE4142A@experienbd1776>
References: <4d6de31b0909220452m14ad62e7q8cb3d7fbd077c849@mail.gmail.com>	<000001ca4015$a5d28a90$f1779fb0$@co.uk>
	<885EC2706E264CC992EE7195BDE4142A@experienbd1776>
Message-ID: <032a01ca404b$15293f30$3f7bbd90$@net>

Hi everyone!

I've got a pretty confusing network situation at a customer's site and hope
that anyone of you could guide me in the right direction...



      |                       | 
   Internet - - - GRE - - - Internet
      |                       |
      |                       |
============              ============
| Router A |              | Router B |
============              ============
      |                       |
      | Cat5                  | Leased Line
      |                       |
============              ============
| Switch 1 |--------------| Switch 2 |
============     LL       ============
      |                       |
      | Cat 5                 | Cat 5
      |                       |
============              ============
| Router C |              | Router D |
============              ============




Router A, B, C and D have iBGP peerings to each other over the two switches.
All the routers are in the same subnet (10.0.0.0/28)!!!
Router A and B are connected to the Internet. They announce the whole
netblock. The problem is, that if the leased line 
between both switches or between Switch 2 and Router B goes down, C and D
will have huge connectivity problems (of course) :-(

There is no other way to connect those routers together as there are a
couple of kilometers in between.

What would be the best solution that if a leased line goes down, packets
that come in to Router A still find their way to Router D and packets that
come in to Router B find their way to Router C?
Route Reflecting, OSPF, ...?



Thanks and kind regards,
Bernd




From mcgrath at fas.harvard.edu  Mon Sep 28 11:26:57 2009
From: mcgrath at fas.harvard.edu (Scott McGrath)
Date: Mon, 28 Sep 2009 11:26:57 -0400
Subject: [c-nsp] Pile on the 6509 noob
In-Reply-To: <200909281743.21346.mtinka@globaltransit.net>
References: <C6E1121E.4FD6%cisco@peakpeak.com>
	<200909281743.21346.mtinka@globaltransit.net>
Message-ID: <4AC0D5C1.9060901@fas.harvard.edu>

Personally,

The 6509 was never optimal for WAN usage it's a excellent ethernet 
router,   What we have
done is use a 7206 or similar router for WAN service and connected it to 
the 65xx via ethernet
one this isolates your WAN circuits so in the event Zeus tosses a 
thunderbolt your way you blow
up an inexpensive router (relatively) and the 65xx is protected due to 
the only connection
being optical (assuming GE interfaces here).

Also the 72xx has many WAN specific features in IOS which are not in the 
65xx's code train
or were not the last time I actively looked.

- Scott

Mark Tinka wrote:
> On Friday 25 September 2009 02:10:06 am CJ wrote:
>
>   
>> Finally, if I solved this issue, I'm wondering about the
>> relative wisdom of using the FlexWAN card.  I want to put
>> a PA-2DS3 in it and also a PA-MC-T3. Is this an
>> enlightened practice?
>>     
>
> We've always been against trying to turn an Ethernet box 
> into a TDM/SONET/SDH device, as it's never cheap considering 
> how much bandwidth you're losing per slot relative to the 
> investment in adding non-Ethernet support as well as the 
> kind of bandwidth you'd be getting out of it.
>
> It's the same thing Juniper did with their MX-FPC carrier 
> cards, adding support for SONET/SDH PIC's in the MX-series 
> routers. I'd still find it cheaper to buy a smaller box that 
> talks Ethernet and non-Ethernet fairly equally from an 
> overall cost/benefit-perspective.
>
> But that's just us :-)... I'm sure a number of networks in 
> the wild find this feature quite useful, which is why the 
> vendors continue to find ways to provide support for it.
>
> Cheers,
>
> Mark.
>   


From Vincent.Abello at ps.net  Mon Sep 28 12:06:26 2009
From: Vincent.Abello at ps.net (Abello, Vinny)
Date: Mon, 28 Sep 2009 11:06:26 -0500
Subject: [c-nsp] So when is IPv6 failover coming to the ASA?
Message-ID: <A47E89A512E4FF4492CA4DE10D7B7C900255E6077C@pscdalpexmb02.perotsystems.net>

Hi all,

 

Anyone have information on when Cisco will actually have support for IPv6 on
the Cisco ASA when in a failover configuration? It is getting a little
ridiculous that there is no security device from Cisco that supports IPv6 in
a redundant configuration, even in 8.2(1). Please someone correct me if I'm
wrong. I'd love to be wrong so I can actually start using IPv6 since I went
through the trouble of building out my core for it quite some time ago. J
Seems everyone just goes to a different vendor because of lack of support.

 

Thanks!

 

Vinny Abello

Implementation Technical Lead

 <mailto:vincent.abello at ps.net> vincent.abello at ps.net

973-940-6125

 

Tellurian Networks | a perotsystemsR company

 <http://www.tellurian.com/> http://www.tellurian.com      888-TELLURIAN
973-300-9211

For all time sensitive issues, please email your request to
<mailto:support at tellurian.com> support at tellurian.com. 

 If your request is urgent, please call our NOC at 973-940-6200.

 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5185 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090928/8ea539fe/attachment.bin>

From geoff at pendery.net  Mon Sep 28 12:07:58 2009
From: geoff at pendery.net (Geoffrey Pendery)
Date: Mon, 28 Sep 2009 11:07:58 -0500
Subject: [c-nsp] Pile on the 6509 noob
In-Reply-To: <4AC0D5C1.9060901@fas.harvard.edu>
References: <C6E1121E.4FD6%cisco@peakpeak.com>
	<200909281743.21346.mtinka@globaltransit.net>
	<4AC0D5C1.9060901@fas.harvard.edu>
Message-ID: <d6966e4b0909280907n6b7400ecga9a0d59fc191c872@mail.gmail.com>

Agreed, and this is what we do as well.
If your WAN is DS3 or smaller, 3845's work well for us.  If OC3 or
bigger, 7206VXR's have worked great for us.  We're starting to dabble
in ASR 1000's for multi-OC3 sites, and they seem promising, but we
don't have enough experience with them to fully recommend yet.

Pretty much all of these options will be cheaper, more robust, and
better supported than FlexWAN, but I don't know the details of your
specific network design and situation, so I'll just agree with Scott
that a separate router has a lot of benefits to it.


-Geoff


On Mon, Sep 28, 2009 at 10:26 AM, Scott McGrath <mcgrath at fas.harvard.edu> wrote:
> Personally,
>
> The 6509 was never optimal for WAN usage it's a excellent ethernet router,
> What we have
> done is use a 7206 or similar router for WAN service and connected it to the
> 65xx via ethernet
> one this isolates your WAN circuits so in the event Zeus tosses a
> thunderbolt your way you blow
> up an inexpensive router (relatively) and the 65xx is protected due to the
> only connection
> being optical (assuming GE interfaces here).
>
> Also the 72xx has many WAN specific features in IOS which are not in the
> 65xx's code train
> or were not the last time I actively looked.
>
> - Scott
>
> Mark Tinka wrote:
>>
>> On Friday 25 September 2009 02:10:06 am CJ wrote:
>>
>>
>>>
>>> Finally, if I solved this issue, I'm wondering about the
>>> relative wisdom of using the FlexWAN card. ?I want to put
>>> a PA-2DS3 in it and also a PA-MC-T3. Is this an
>>> enlightened practice?
>>>
>>
>> We've always been against trying to turn an Ethernet box into a
>> TDM/SONET/SDH device, as it's never cheap considering how much bandwidth
>> you're losing per slot relative to the investment in adding non-Ethernet
>> support as well as the kind of bandwidth you'd be getting out of it.
>>
>> It's the same thing Juniper did with their MX-FPC carrier cards, adding
>> support for SONET/SDH PIC's in the MX-series routers. I'd still find it
>> cheaper to buy a smaller box that talks Ethernet and non-Ethernet fairly
>> equally from an overall cost/benefit-perspective.
>>
>> But that's just us :-)... I'm sure a number of networks in the wild find
>> this feature quite useful, which is why the vendors continue to find ways to
>> provide support for it.
>>
>> Cheers,
>>
>> Mark.
>>
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From A.L.M.Buxey at lboro.ac.uk  Mon Sep 28 12:12:48 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Mon, 28 Sep 2009 17:12:48 +0100
Subject: [c-nsp] So when is IPv6 failover coming to the ASA?
In-Reply-To: <A47E89A512E4FF4492CA4DE10D7B7C900255E6077C@pscdalpexmb02.perotsystems.net>
References: <A47E89A512E4FF4492CA4DE10D7B7C900255E6077C@pscdalpexmb02.perotsystems.net>
Message-ID: <20090928161248.GT7045@lboro.ac.uk>

Hi,

> Anyone have information on when Cisco will actually have support for IPv6 on
> the Cisco ASA when in a failover configuration? It is getting a little

when we originally purchased our ASA solution we were told spring 09.
that then slipped to nov 09 and then into the new year - cant tell yout he current
proposed date because thats under NDA (though everyone whos ever asked has probably
also been told the same date) - I think the current situation is awful.

sure, i could just about cope with the current live sessions being lost...but
at least allow such basic failover to work! :-(

currently we have to turn the IPv6 off and then turn it back on again.
the kit from 'J' doesnt need that kind of close love in times of disaster

alan

From Vincent.Abello at ps.net  Mon Sep 28 13:13:14 2009
From: Vincent.Abello at ps.net (Abello, Vinny)
Date: Mon, 28 Sep 2009 12:13:14 -0500
Subject: [c-nsp] So when is IPv6 failover coming to the ASA?
In-Reply-To: <20090928161248.GT7045@lboro.ac.uk>
References: <A47E89A512E4FF4492CA4DE10D7B7C900255E6077C@pscdalpexmb02.perotsystems.net>
	<20090928161248.GT7045@lboro.ac.uk>
Message-ID: <A47E89A512E4FF4492CA4DE10D7B7C900255E60816@pscdalpexmb02.perotsystems.net>

I don't care so much at this point if it fails over or not. If I were to
configure it, would it at least work as far as passing the traffic? I
thought I read early on that it would cause a conflict between the two ASA
devices or is this not the case? If that's all I have to worry about, it's
not critical that it fails over automatically at this point for me. It's
more of an initial staging of the technology so I can start numbering my
devices and verify connectivity, etc... As you said, you turn IPv6 off and
back on. Is that all that's needed at this point in time? I can deal with
that for the time being.

Thanks for the info!

-Vinny

-----Original Message-----
From: Alan Buxey [mailto:A.L.M.Buxey at lboro.ac.uk] 
Sent: Monday, September 28, 2009 12:13 PM
To: Abello, Vinny
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] So when is IPv6 failover coming to the ASA?

Hi,

> Anyone have information on when Cisco will actually have support for IPv6
on
> the Cisco ASA when in a failover configuration? It is getting a little

when we originally purchased our ASA solution we were told spring 09.
that then slipped to nov 09 and then into the new year - cant tell yout he
current
proposed date because thats under NDA (though everyone whos ever asked has
probably
also been told the same date) - I think the current situation is awful.

sure, i could just about cope with the current live sessions being
lost...but
at least allow such basic failover to work! :-(

currently we have to turn the IPv6 off and then turn it back on again.
the kit from 'J' doesnt need that kind of close love in times of disaster

alan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5185 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090928/cf00633d/attachment-0001.bin>

From vitya at list.ru  Mon Sep 28 13:27:54 2009
From: vitya at list.ru (victor)
Date: Mon, 28 Sep 2009 21:27:54 +0400
Subject: [c-nsp] send multicast over non-multicast-enabled switch
Message-ID: <op.u0y7o82a2vrlim@localhost.localdomain>

Hi.
I was assigned with a task to set up a video streaming server and use a  
blade server for it. The problem is that the network connectivity module  
for the blade chassis is not dotQ multicast aware and simply drop all the  
224.0.0.0/4 data. What options do I have to get the traffic through? I am  
thinking may be it is possible to encapsulate the stream into gre and then  
safely transport it to the RP? Or may be I can send it as unicast and then  
convert it somehow into multicast? Is there a best practices guide for  
this matter?
The blade runs Linux and over the trunk connected to the RP which is Cisco  
7604.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From nick at inex.ie  Mon Sep 28 13:38:49 2009
From: nick at inex.ie (Nick Hilliard)
Date: Mon, 28 Sep 2009 18:38:49 +0100
Subject: [c-nsp] So when is IPv6 failover coming to the ASA?
In-Reply-To: <A47E89A512E4FF4492CA4DE10D7B7C900255E60816@pscdalpexmb02.perotsystems.net>
References: <A47E89A512E4FF4492CA4DE10D7B7C900255E6077C@pscdalpexmb02.perotsystems.net>	<20090928161248.GT7045@lboro.ac.uk>
	<A47E89A512E4FF4492CA4DE10D7B7C900255E60816@pscdalpexmb02.perotsystems.net>
Message-ID: <4AC0F4A9.3010002@inex.ie>

On 28/09/2009 18:13, Abello, Vinny wrote:
> I don't care so much at this point if it fails over or not. If I were to
> configure it, would it at least work as far as passing the traffic? I
> thought I read early on that it would cause a conflict between the two ASA
> devices or is this not the case? If that's all I have to worry about, it's
> not critical that it fails over automatically at this point for me. It's
> more of an initial staging of the technology so I can start numbering my
> devices and verify connectivity, etc... As you said, you turn IPv6 off and
> back on. Is that all that's needed at this point in time? I can deal with
> that for the time being.

It certainly passes traffic and performs stateful packet firewalling.  It 
doesn't do inspection very well, and failover is documented as not implemented.

What I have observed is that these things are overlooked during 
specification because you feel that you can live with an occasional amount 
of pain. But once you get the boxes into production, you'll find that ipv6 
breaks at times which are, well, frankly rather inconvenient, like during 
time-constrained maintenance windows or when a switch crashes or reboots or 
whatever.

This isn't intended as a jab at Cisco or anything - ipv6 failover is well 
documented as not being implemented yet and, well, that's that.  It's a 
known failure mode.  It's just that we're all human and because failover 
often occurs under times of extreme network stress, end-users and 
management may get unhappy and may start shouting and colourful verbal 
incantations may be invoked when ipv6 stops working all of a sudden.

Unfortunately, ASA boxes are beloved of enterprises, and ipv6 is very much 
down the list as far as the enterprise market segment is concerned.  The 
service provider market has significantly different needs, but Cisco's ASA 
product managers are not especially focussed on this segment.

Nick

From A.L.M.Buxey at lboro.ac.uk  Mon Sep 28 13:51:43 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Mon, 28 Sep 2009 18:51:43 +0100
Subject: [c-nsp] So when is IPv6 failover coming to the ASA?
In-Reply-To: <4AC0F4A9.3010002@inex.ie>
References: <A47E89A512E4FF4492CA4DE10D7B7C900255E6077C@pscdalpexmb02.perotsystems.net>
	<20090928161248.GT7045@lboro.ac.uk>
	<A47E89A512E4FF4492CA4DE10D7B7C900255E60816@pscdalpexmb02.perotsystems.net>
	<4AC0F4A9.3010002@inex.ie>
Message-ID: <20090928175143.GA8804@lboro.ac.uk>

Hi,

> It certainly passes traffic and performs stateful packet firewalling.  It 
> doesn't do inspection very well, and failover is documented as not 
> implemented.

as Nick has said - it'll do the stuff when its alive and working.

just dont expect to use the ADSM mgmt console to do any IPv6 stuff either.
so thoes who can only use GUI tools and dont do, cant do CLI stuff..well,
tough  :-)


PS on another note, I've found with the ASA that if you specify
a UDP_TCP rule - eg DNS/53 then it doesnt quite work right.
seperate 53 UDP and 53 TCP, things are fine - i've either mis-understoof
the UDP/TCP logic in the ASA or *its* logic is wrong. and only
one of us can be right...  ;-)

alan

From nicotine at warningg.com  Mon Sep 28 14:02:26 2009
From: nicotine at warningg.com (Brandon Ewing)
Date: Mon, 28 Sep 2009 13:02:26 -0500
Subject: [c-nsp] So when is IPv6 failover coming to the ASA?
In-Reply-To: <20090928175143.GA8804@lboro.ac.uk>
References: <A47E89A512E4FF4492CA4DE10D7B7C900255E6077C@pscdalpexmb02.perotsystems.net>
	<20090928161248.GT7045@lboro.ac.uk>
	<A47E89A512E4FF4492CA4DE10D7B7C900255E60816@pscdalpexmb02.perotsystems.net>
	<4AC0F4A9.3010002@inex.ie> <20090928175143.GA8804@lboro.ac.uk>
Message-ID: <20090928180226.GA24495@radiological.warningg.com>

On Mon, Sep 28, 2009 at 06:51:43PM +0100, Alan Buxey wrote:
> Hi,
> 
> PS on another note, I've found with the ASA that if you specify
> a UDP_TCP rule - eg DNS/53 then it doesnt quite work right.
> seperate 53 UDP and 53 TCP, things are fine - i've either mis-understoof
> the UDP/TCP logic in the ASA or *its* logic is wrong. and only
> one of us can be right...  ;-)
> 

TCP/UDP rules still require two rules to be listed in 7.x and 8.0, one with
protocol TCP, one with protocol UDP, or be utilized with a protocol-group of
tcp-udp.  

If you expand the access-list with "show run access-list name", you can see
the indidivual rules applied.

8.2 introduces "dual-service-object-group mode" -- meaning you can define a
service group WITHOUT the protocol specifiction at the end, and define
protocls on a per-service basis:

object-group service TEST
 service-object tcp-udp eq domain
 service-object tcp eq www
 service-object icmp echo
!

Then utilize it in an ACL:
access-list TEST-ACL permit object-group TEST any host 1.2.3.4

-- 
Brandon Ewing                                        (nicotine at warningg.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090928/c53e232f/attachment.bin>

From blocke at newpaltz.edu  Mon Sep 28 14:26:45 2009
From: blocke at newpaltz.edu (Bruce A. Locke)
Date: Mon, 28 Sep 2009 14:26:45 -0400 (EDT)
Subject: [c-nsp] Non-Java download option
In-Reply-To: <4ABDD190.2030702@inex.ie>
Message-ID: <1400039126.2611051254162405361.JavaMail.root@zmail.newpaltz.edu>


----- "Nick Hilliard" <nick at inex.ie> wrote:

| http://tools.cisco.com/support/downloads/go/ManualDownload.x
| 
| Thank you, Cisco!


Now that the manual download option is in the new way of downloading IOS is a bit less confusing so it is definitely an improvement.  A couple extra clicks but having the release notes link right there makes up for it.

Thanks Cisco!


-- 
Bruce A. Locke
blocke at newpaltz.edu
HAB 50 - (845) 257-3809

Network Administrator
Computer Services
State University of New York at New Paltz 


From david.freedman at uk.clara.net  Mon Sep 28 14:27:11 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Mon, 28 Sep 2009 19:27:11 +0100
Subject: [c-nsp] Another bughunt, this time VRF PBR
In-Reply-To: <7B8B0D6F623C3A40A0D0A80A66756E2B2C2F18@EXVS01.claranet.local>
References: <7B8B0D6F623C3A40A0D0A80A66756E2B2C2F13@EXVS01.claranet.local>	<4AC02818.1020104@justinshore.com>
	<7B8B0D6F623C3A40A0D0A80A66756E2B2C2F18@EXVS01.claranet.local>
Message-ID: <h9qv5v$c0i$1@ger.gmane.org>

Have just tried with another live box running SRD (the original SRD) -
exactly the same story.

Does anybody know if this is supported or not? I'm not seeing any
documentation which suggests it is not.

David.

David Freedman wrote:
> Yes, I woul absolutely love to, believe me :)
> Need to make sure nobody steps in at this point and claims that this is unsupported, if it is then am happy
> to move it to SR and away from 12.4(T) completely.
> 
> ------------------------------------------------
> David Freedman
> Group Network Engineering 
> Claranet Limited
> http://www.clara.net
> 
> 
> 
> -----Original Message-----
> From: Justin Shore [mailto:justin at justinshore.com]
> Sent: Mon 9/28/2009 04:06
> To: David Freedman
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Another bughunt, this time VRF PBR
>  
> David Freedman wrote:
>> wonder if anybody has come across this before,
>>
>> in 12.4(15)T, configuring a virtual-access per-user such:
> 
> I hate to suggest the obvious but since there are so many bugs in 
> 12.4(15)T have you considered bumping that to the latest minor rev?  I 
> think they're up to T7 or T8 now (must have been some bug list).
> 
> Justin
> 
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


From david.freedman at uk.clara.net  Mon Sep 28 14:53:27 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Mon, 28 Sep 2009 19:53:27 +0100
Subject: [c-nsp] Another bughunt, this time VRF PBR
In-Reply-To: <h9qv5v$c0i$1@ger.gmane.org>
References: <7B8B0D6F623C3A40A0D0A80A66756E2B2C2F13@EXVS01.claranet.local>	<4AC02818.1020104@justinshore.com>	<7B8B0D6F623C3A40A0D0A80A66756E2B2C2F18@EXVS01.claranet.local>
	<h9qv5v$c0i$1@ger.gmane.org>
Message-ID: <h9r0n7$ha3$1@ger.gmane.org>

Hah, SRD2a is even odder, refuses to even install the per-user vrf static!

This has however enabled me to home in on CSCsu33006 which sounds more
likely, but it claims to be fixed in SRC4 and SRD which is annoying.

Dave.


David Freedman wrote:
> Have just tried with another live box running SRD (the original SRD) -
> exactly the same story.
> 
> Does anybody know if this is supported or not? I'm not seeing any
> documentation which suggests it is not.
> 
> David.
> 
> David Freedman wrote:
>> Yes, I woul absolutely love to, believe me :)
>> Need to make sure nobody steps in at this point and claims that this is unsupported, if it is then am happy
>> to move it to SR and away from 12.4(T) completely.
>>
>> ------------------------------------------------
>> David Freedman
>> Group Network Engineering 
>> Claranet Limited
>> http://www.clara.net
>>
>>
>>
>> -----Original Message-----
>> From: Justin Shore [mailto:justin at justinshore.com]
>> Sent: Mon 9/28/2009 04:06
>> To: David Freedman
>> Cc: cisco-nsp at puck.nether.net
>> Subject: Re: [c-nsp] Another bughunt, this time VRF PBR
>>  
>> David Freedman wrote:
>>> wonder if anybody has come across this before,
>>>
>>> in 12.4(15)T, configuring a virtual-access per-user such:
>> I hate to suggest the obvious but since there are so many bugs in 
>> 12.4(15)T have you considered bumping that to the latest minor rev?  I 
>> think they're up to T7 or T8 now (must have been some bug list).
>>
>> Justin
>>
>>
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


From kwoody at citytel.net  Mon Sep 28 14:28:53 2009
From: kwoody at citytel.net (Keith)
Date: Mon, 28 Sep 2009 11:28:53 -0700 (PDT)
Subject: [c-nsp] fsck disk0: 7206vxr
Message-ID: <20090928111905.K50663@pop.citytel.net>


Question re: fsck'ing disk0:.

We had a problem with an NSE-1 on our 7206vxr a few weeks ago and replaced
it with a NPE-400.

In cleaning up some of the crashinfo's from disk0: the other day I get
this:

%Error deleting disk0:crashinfo_20090904-095818 (Cluster chain broken on
file)

Would a simple fsck disk0: remedy this? I have done fsck on lab routers
with no load or anything on them to see how it works, but there has never
really been a problem with the lab routers like I have above. This one
is production and I am wondering what affect running fsck might have?

Thanks,
Keith

From nicotine at warningg.com  Mon Sep 28 15:48:47 2009
From: nicotine at warningg.com (Brandon Ewing)
Date: Mon, 28 Sep 2009 14:48:47 -0500
Subject: [c-nsp] Cisco config traps generated at wrong time?
Message-ID: <20090928194847.GB24495@radiological.warningg.com>

Greetings,

Weird issue.  I'm investigating utilizing Cisco's SNMP trap generation to
trigger RANCID runs against specific routers.  In my initial testing, I am
able to get the routers to generate traps, but according to the
documentation, it appears to be generating the traps at the wrong time.

The config trap is generated immediately after I issue "conf t" from the
CLI, before I actually make any changes or exit configuration mode.
According to the MIB browser, this is incorrect:

(from
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=1.3.6.1.4.1.9.9.43.2.0.2)

If the managed system supports a separate
configuration mode(where the configuration commands
are entered under a configuration session which
affects the running configuration of the system),
then this notification is sent when the configuration
mode is exited.

I have noticed this on 12.2(33) SXI1, and in a dynamips lab running 
12.4(25a).  Searches of the bug toolkit didn't turn up anything.  Has anyone
else gotten this to work as intended on any other version of IOS?

My fallback will be to utilize syslogging, as it generates the log entries
on exit instead of enter.

-- 
Brandon Ewing                                        (nicotine at warningg.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090928/8c47212f/attachment-0001.bin>

From avayner at cisco.com  Mon Sep 28 15:52:21 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Mon, 28 Sep 2009 21:52:21 +0200
Subject: [c-nsp] send multicast over non-multicast-enabled switch
In-Reply-To: <op.u0y7o82a2vrlim@localhost.localdomain>
References: <op.u0y7o82a2vrlim@localhost.localdomain>
Message-ID: <FDD1CDB3FB499E4087CC7670BBCA22C6581B69@XMB-AMS-101.cisco.com>

Victor,

You could actually use GRE for that. The 7600 can do GRE in hardware
(assuming you have Sup720 and up).

You need to make sure that the multicast source would be an IP routed
through the GRE tunnel on the 7600, or else you would get RPF failures.

I would say the best practice would be to get a switch that can handle
multicast, and the above would be a workaround.

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of victor
Sent: Monday, September 28, 2009 19:28
To: cisco-nsp at puck.nether.net
Cc: cisco-nsp at puck.nether.net
Subject: [c-nsp] send multicast over non-multicast-enabled switch

Hi.
I was assigned with a task to set up a video streaming server and use a

blade server for it. The problem is that the network connectivity module

for the blade chassis is not dotQ multicast aware and simply drop all
the  
224.0.0.0/4 data. What options do I have to get the traffic through? I
am  
thinking may be it is possible to encapsulate the stream into gre and
then  
safely transport it to the RP? Or may be I can send it as unicast and
then  
convert it somehow into multicast? Is there a best practices guide for  
this matter?
The blade runs Linux and over the trunk connected to the RP which is
Cisco  
7604.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From panocisco77 at gmail.com  Mon Sep 28 16:39:43 2009
From: panocisco77 at gmail.com (Renelson Panosky)
Date: Mon, 28 Sep 2009 16:39:43 -0400
Subject: [c-nsp] Cisco 4948 with a SAN fiber over ethernet ( Dell equallogic
	series)
Message-ID: <16e2ac180909281339i42a5d966p8caf5749e47b61af@mail.gmail.com>

I am trying to set up this SAN with some 4948 and I am going to connect them
to my network, Can anybody help me with this?

Which protocol is best for this ? layer 2 ? or layer ?

The Equallogic has two storage modules and each one has four Ethernet ports
(1 Gb).

I would like to be able to do replication from the SAN devices between on
network and the other and also do SAN management from the LAN.

I know i can connect the 4948 to one of the switch on my network and connect
the server on the 4948.
create some trunk link between 4948 and the switch, create some vlan to
segmentted my vlan communication form SAN communication.

Please let me know if i got right or what is the best practice, anything
would help because i want to have as much as information i can so i have
some options

From mylists at battleop.com  Mon Sep 28 16:54:59 2009
From: mylists at battleop.com (Richey)
Date: Mon, 28 Sep 2009 16:54:59 -0400
Subject: [c-nsp] Smartnet pricing?
Message-ID: <01d401ca407d$f1797900$d46c6b00$@com>

One of my customers called me today to ask me if this sounds right.  I don't
much about smartnet but I told him I knew where to ask about this.    He
said they let their initial smartnet contract expire about 5 years ago
because they never used the support and management couldn't justify the
cost.    Now they need a newer image because the current one they are using
is buggy for whatever it is they are trying to do.     They contacted their
"rep"  and the rep said Cisco wants them to pay for the last 5 years of
smartnet plus however many going forward  in order to get the image.  They
were quoted over $25k just to upgrade an image.   The part that sounds fishy
is being forced to pay for 5 years of smartnet.   Does this sound right?

 

Richey


From mhuff at ox.com  Mon Sep 28 17:01:56 2009
From: mhuff at ox.com (Matthew Huff)
Date: Mon, 28 Sep 2009 17:01:56 -0400
Subject: [c-nsp] Smartnet pricing?
In-Reply-To: <01d401ca407d$f1797900$d46c6b00$@com>
References: <01d401ca407d$f1797900$d46c6b00$@com>
Message-ID: <483E6B0272B0284BA86D7596C40D29F9D7738E68F6@PUR-EXCH07.ox.com>

It's not unusual practice in the industry, but usually Cisco will require a "recertification" fee instead. They will send someone out to make sure the equipment is still working etc... It's usually about 2-3 x the cost of an annual contract. You might see if they will do a recert instead. Otherwise, maybe your customer will learn about being pennywise and pound foolish :)



----
Matthew Huff?????? | One Manhattanville Rd
OTA Management LLC | Purchase, NY 10577
http://www.ox.com? | Phone: 914-460-4039
aim: matthewbhuff? | Fax:?? 914-460-4139


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Richey
Sent: Monday, September 28, 2009 4:55 PM
To: 'Cisco-NSP Mailing List'
Subject: [c-nsp] Smartnet pricing?

One of my customers called me today to ask me if this sounds right.  I don't
much about smartnet but I told him I knew where to ask about this.    He
said they let their initial smartnet contract expire about 5 years ago
because they never used the support and management couldn't justify the
cost.    Now they need a newer image because the current one they are using
is buggy for whatever it is they are trying to do.     They contacted their
"rep"  and the rep said Cisco wants them to pay for the last 5 years of
smartnet plus however many going forward  in order to get the image.  They
were quoted over $25k just to upgrade an image.   The part that sounds fishy
is being forced to pay for 5 years of smartnet.   Does this sound right?

 

Richey

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From jared at puck.nether.net  Mon Sep 28 17:11:17 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 28 Sep 2009 17:11:17 -0400
Subject: [c-nsp] Smartnet pricing?
In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D7738E68F6@PUR-EXCH07.ox.com>
References: <01d401ca407d$f1797900$d46c6b00$@com>
	<483E6B0272B0284BA86D7596C40D29F9D7738E68F6@PUR-EXCH07.ox.com>
Message-ID: <C5883DC4-1709-4844-A787-1B12D5406D48@puck.nether.net>

Look for a PSIRT issue against the image and get a 'free' upgrade?

	- Jared

On Sep 28, 2009, at 5:01 PM, Matthew Huff wrote:

> It's not unusual practice in the industry, but usually Cisco will  
> require a "recertification" fee instead. They will send someone out  
> to make sure the equipment is still working etc... It's usually  
> about 2-3 x the cost of an annual contract. You might see if they  
> will do a recert instead. Otherwise, maybe your customer will learn  
> about being pennywise and pound foolish :)
>
>
>
> ----
> Matthew Huff       | One Manhattanville Rd
> OTA Management LLC | Purchase, NY 10577
> http://www.ox.com  | Phone: 914-460-4039
> aim: matthewbhuff  | Fax:   914-460-4139
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- 
> bounces at puck.nether.net] On Behalf Of Richey
> Sent: Monday, September 28, 2009 4:55 PM
> To: 'Cisco-NSP Mailing List'
> Subject: [c-nsp] Smartnet pricing?
>
> One of my customers called me today to ask me if this sounds right.   
> I don't
> much about smartnet but I told him I knew where to ask about  
> this.    He
> said they let their initial smartnet contract expire about 5 years ago
> because they never used the support and management couldn't justify  
> the
> cost.    Now they need a newer image because the current one they  
> are using
> is buggy for whatever it is they are trying to do.     They  
> contacted their
> "rep"  and the rep said Cisco wants them to pay for the last 5 years  
> of
> smartnet plus however many going forward  in order to get the  
> image.  They
> were quoted over $25k just to upgrade an image.   The part that  
> sounds fishy
> is being forced to pay for 5 years of smartnet.   Does this sound  
> right?
>
>
>
> Richey
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From gsgranados at comcast.net  Mon Sep 28 17:17:32 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Mon, 28 Sep 2009 14:17:32 -0700
Subject: [c-nsp] Smartnet pricing?
References: <01d401ca407d$f1797900$d46c6b00$@com>
Message-ID: <005f01ca4081$1cfef430$2408120a@am.thmulti.com>

I think Cisco is smoking crack here and not that good quality East Oakland 
stovetop crack but that San Francisco twice cut Tenderloin shwag. Consider 
that you can buy used hardware from a reputable reseller and resmartnet the 
gear for very reasonable rates certainly far less than 5X.  (generally 1X in 
my experience) so I don't see how you'd get charged 5 times for your own 
gear and the normal street rate for gear off Ebay or your friendly near by 
used reseller.  I'd say some haggling is in order.


----- Original Message ----- 
From: "Richey" <mylists at battleop.com>
To: "'Cisco-NSP Mailing List'" <cisco-nsp at puck.nether.net>
Sent: Monday, September 28, 2009 1:54 PM
Subject: [c-nsp] Smartnet pricing?


> One of my customers called me today to ask me if this sounds right.  I 
> don't
> much about smartnet but I told him I knew where to ask about this.    He
> said they let their initial smartnet contract expire about 5 years ago
> because they never used the support and management couldn't justify the
> cost.    Now they need a newer image because the current one they are 
> using
> is buggy for whatever it is they are trying to do.     They contacted 
> their
> "rep"  and the rep said Cisco wants them to pay for the last 5 years of
> smartnet plus however many going forward  in order to get the image.  They
> were quoted over $25k just to upgrade an image.   The part that sounds 
> fishy
> is being forced to pay for 5 years of smartnet.   Does this sound right?
>
>
>
> Richey
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From avayner at cisco.com  Mon Sep 28 17:26:21 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Mon, 28 Sep 2009 23:26:21 +0200
Subject: [c-nsp] fsck disk0: 7206vxr
In-Reply-To: <20090928111905.K50663@pop.citytel.net>
References: <20090928111905.K50663@pop.citytel.net>
Message-ID: <FDD1CDB3FB499E4087CC7670BBCA22C6581B91@XMB-AMS-101.cisco.com>

Keith,

I looked at some reference cases similar to this one, and in some cases
FSCK helps, but in some a format was required...

You could just copy the files to a file server (FTP/TFTP), format, and
then copy the files back.

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Keith
Sent: Monday, September 28, 2009 20:29
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] fsck disk0: 7206vxr


Question re: fsck'ing disk0:.

We had a problem with an NSE-1 on our 7206vxr a few weeks ago and
replaced
it with a NPE-400.

In cleaning up some of the crashinfo's from disk0: the other day I get
this:

%Error deleting disk0:crashinfo_20090904-095818 (Cluster chain broken on
file)

Would a simple fsck disk0: remedy this? I have done fsck on lab routers
with no load or anything on them to see how it works, but there has
never
really been a problem with the lab routers like I have above. This one
is production and I am wondering what affect running fsck might have?

Thanks,
Keith
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From jkrejci at usinternet.com  Mon Sep 28 17:21:00 2009
From: jkrejci at usinternet.com (Justin Krejci)
Date: Mon, 28 Sep 2009 16:21:00 -0500
Subject: [c-nsp] Smartnet pricing?
In-Reply-To: <C5883DC4-1709-4844-A787-1B12D5406D48@puck.nether.net>
References: <01d401ca407d$f1797900$d46c6b00$@com><483E6B0272B0284BA86D7596C40D29F9D7738E68F6@PUR-EXCH07.ox.com>
	<C5883DC4-1709-4844-A787-1B12D5406D48@puck.nether.net>
Message-ID: <AE047782A4A04CB2A7DA7171BADA765A@usicorp.usinternet.com>

Replace (upgrade?) the hardware and get a new contract? Then you have a
spare too.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jared Mauch
Sent: Monday, September 28, 2009 4:11 PM
To: Matthew Huff
Cc: 'Cisco-NSP Mailing List'
Subject: Re: [c-nsp] Smartnet pricing?

Look for a PSIRT issue against the image and get a 'free' upgrade?

	- Jared

On Sep 28, 2009, at 5:01 PM, Matthew Huff wrote:

> It's not unusual practice in the industry, but usually Cisco will  
> require a "recertification" fee instead. They will send someone out  
> to make sure the equipment is still working etc... It's usually  
> about 2-3 x the cost of an annual contract. You might see if they  
> will do a recert instead. Otherwise, maybe your customer will learn  
> about being pennywise and pound foolish :)
>
>
>
> ----
> Matthew Huff       | One Manhattanville Rd
> OTA Management LLC | Purchase, NY 10577
> http://www.ox.com  | Phone: 914-460-4039
> aim: matthewbhuff  | Fax:   914-460-4139
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- 
> bounces at puck.nether.net] On Behalf Of Richey
> Sent: Monday, September 28, 2009 4:55 PM
> To: 'Cisco-NSP Mailing List'
> Subject: [c-nsp] Smartnet pricing?
>
> One of my customers called me today to ask me if this sounds right.   
> I don't
> much about smartnet but I told him I knew where to ask about  
> this.    He
> said they let their initial smartnet contract expire about 5 years ago
> because they never used the support and management couldn't justify  
> the
> cost.    Now they need a newer image because the current one they  
> are using
> is buggy for whatever it is they are trying to do.     They  
> contacted their
> "rep"  and the rep said Cisco wants them to pay for the last 5 years  
> of
> smartnet plus however many going forward  in order to get the  
> image.  They
> were quoted over $25k just to upgrade an image.   The part that  
> sounds fishy
> is being forced to pay for 5 years of smartnet.   Does this sound  
> right?
>
>
>
> Richey
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From sethm at rollernet.us  Mon Sep 28 18:31:29 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Mon, 28 Sep 2009 15:31:29 -0700
Subject: [c-nsp] Smartnet pricing?
In-Reply-To: <01d401ca407d$f1797900$d46c6b00$@com>
References: <01d401ca407d$f1797900$d46c6b00$@com>
Message-ID: <4AC13941.4080106@rollernet.us>

Richey wrote:
> One of my customers called me today to ask me if this sounds right.  I don't
> much about smartnet but I told him I knew where to ask about this.    He
> said they let their initial smartnet contract expire about 5 years ago
> because they never used the support and management couldn't justify the
> cost.    Now they need a newer image because the current one they are using
> is buggy for whatever it is they are trying to do.     They contacted their
> "rep"  and the rep said Cisco wants them to pay for the last 5 years of
> smartnet plus however many going forward  in order to get the image.  They
> were quoted over $25k just to upgrade an image.   The part that sounds fishy
> is being forced to pay for 5 years of smartnet.   Does this sound right?
> 

I once added smartnet to a 2811 over a year after purchasing it without.
I didn't have to pay a recert or for the uncovered time.

-- 
Seth Mattinen		sethm at rollernet.us
Roller Network LLC

From peter at rathlev.dk  Mon Sep 28 19:13:38 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Tue, 29 Sep 2009 01:13:38 +0200
Subject: [c-nsp] Cisco config traps generated at wrong time?
In-Reply-To: <20090928194847.GB24495@radiological.warningg.com>
References: <20090928194847.GB24495@radiological.warningg.com>
Message-ID: <1254179618.12024.2.camel@abehat.net.rm.dk>

On Mon, 2009-09-28 at 14:48 -0500, Brandon Ewing wrote:
> The config trap is generated immediately after I issue "conf t" from
> the CLI, before I actually make any changes or exit configuration
> mode. According to the MIB browser, this is incorrect:
...
> I have noticed this on 12.2(33) SXI1, and in a dynamips lab running 
> 12.4(25a).  Searches of the bug toolkit didn't turn up anything.  Has
> anyone else gotten this to work as intended on any other version of
> IOS?
> 
> My fallback will be to utilize syslogging, as it generates the log
> entries on exit instead of enter.

Same thing for us, we also use the syslog message instead. Hadn't
noticed that the documentation said that though, just thought it was
weird that the box sent a trap when starting the configuration.

-- 
Peter



From judah.scott.iam at gmail.com  Mon Sep 28 21:12:56 2009
From: judah.scott.iam at gmail.com (Judah Scott)
Date: Mon, 28 Sep 2009 18:12:56 -0700
Subject: [c-nsp] Smartnet pricing?
In-Reply-To: <4AC13941.4080106@rollernet.us>
References: <01d401ca407d$f1797900$d46c6b00$@com>
	<4AC13941.4080106@rollernet.us>
Message-ID: <3172b9cb0909281812ifaf0e41n45c5c30f68054b11@mail.gmail.com>

Why don't you tell them that they couldn't sell you at 1x price for the last
5 years, what makes them think you are going to pay 5x that price.  It's
simple economics you obviously value the service at <1/5 the price ...



On Mon, Sep 28, 2009 at 3:31 PM, Seth Mattinen <sethm at rollernet.us> wrote:

> Richey wrote:
> > One of my customers called me today to ask me if this sounds right.  I
> don't
> > much about smartnet but I told him I knew where to ask about this.    He
> > said they let their initial smartnet contract expire about 5 years ago
> > because they never used the support and management couldn't justify the
> > cost.    Now they need a newer image because the current one they are
> using
> > is buggy for whatever it is they are trying to do.     They contacted
> their
> > "rep"  and the rep said Cisco wants them to pay for the last 5 years of
> > smartnet plus however many going forward  in order to get the image.
>  They
> > were quoted over $25k just to upgrade an image.   The part that sounds
> fishy
> > is being forced to pay for 5 years of smartnet.   Does this sound right?
> >
>
> I once added smartnet to a 2811 over a year after purchasing it without.
> I didn't have to pay a recert or for the uncovered time.
>
> --
> Seth Mattinen           sethm at rollernet.us
> Roller Network LLC
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From andy.saykao at staff.netspace.net.au  Tue Sep 29 01:04:29 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Tue, 29 Sep 2009 15:04:29 +1000
Subject: [c-nsp] Which IP's belong to AS1234?
References: <56F211C5E3F24F47B103EA1B253822BE044AAC97@vic-cr-ex1.staff.netspace.net.au>	<4ABC718E.90908@thingy.com>
	<56F211C5E3F24F47B103EA1B253822BE044AAC99@vic-cr-ex1.staff.netspace.net.au>
	<4ABD0215.20407@howells.me>
Message-ID: <56F211C5E3F24F47B103EA1B253822BE044AACBA@vic-cr-ex1.staff.netspace.net.au>

Thanks to all that replied to me about this issue.
A lot to digest and your feedback has been greatly apprecaited.

Cheers.

Andy

This email and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed. 
Please notify the sender immediately by email if you have received this 
email by mistake and delete this email from your system. 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 organisation. 
Finally, the recipient should check this email and any attachments for 
the presence of viruses. The organisation accepts no liability for any 
damage caused by any virus transmitted by this email.


From gkg at gmx.de  Tue Sep 29 01:32:21 2009
From: gkg at gmx.de (Garry)
Date: Tue, 29 Sep 2009 07:32:21 +0200
Subject: [c-nsp] Smartnet pricing?
In-Reply-To: <01d401ca407d$f1797900$d46c6b00$@com>
References: <01d401ca407d$f1797900$d46c6b00$@com>
Message-ID: <4AC19BE5.7040506@gmx.de>

Richey wrote:
> is buggy for whatever it is they are trying to do.     They contacted their
> "rep"  and the rep said Cisco wants them to pay for the last 5 years of
> smartnet plus however many going forward  in order to get the image.  They
> were quoted over $25k just to upgrade an image.   The part that sounds fishy
> is being forced to pay for 5 years of smartnet.   Does this sound right?
>   
Apart from the fact that I've had several occasions where there weren't
any complaints about getting SMARTnet for older gear (and the serial was
sent in when ordering, so $C knew it was older and off of SN for a
while) - If what you're after is the IOS update, and you're being quotet
for the time in between, why not go software-only SMARTnet? It even
contains config/TAC support (if ever required), full access to the
download area, and it's something like half of the regular SNT ... plus,
there's no logical reason to require a re-cert, as your hardware itself
isn't covered ...

-garry

From ssaner at pantheranet.com  Tue Sep 29 01:56:26 2009
From: ssaner at pantheranet.com (Steven Saner)
Date: Tue, 29 Sep 2009 00:56:26 -0500
Subject: [c-nsp] Smartnet pricing?
In-Reply-To: <4AC19BE5.7040506@gmx.de>
References: <01d401ca407d$f1797900$d46c6b00$@com> <4AC19BE5.7040506@gmx.de>
Message-ID: <4AC1A18A.5030900@pantheranet.com>

Garry wrote:
> Richey wrote:
>> is buggy for whatever it is they are trying to do.     They contacted their
>> "rep"  and the rep said Cisco wants them to pay for the last 5 years of
>> smartnet plus however many going forward  in order to get the image.  They
>> were quoted over $25k just to upgrade an image.   The part that sounds fishy
>> is being forced to pay for 5 years of smartnet.   Does this sound right?
>>   
> Apart from the fact that I've had several occasions where there weren't
> any complaints about getting SMARTnet for older gear (and the serial was
> sent in when ordering, so $C knew it was older and off of SN for a
> while) - If what you're after is the IOS update, and you're being quotet
> for the time in between, why not go software-only SMARTnet? It even
> contains config/TAC support (if ever required), full access to the
> download area, and it's something like half of the regular SNT ... plus,
> there's no logical reason to require a re-cert, as your hardware itself
> isn't covered ...

Is this really available? I was asking a SmartNet rep about this once and was 
led to believe this isn't an option. Maybe it wasn't then and is now? Maybe they 
were pulling my leg?

Steve

-- 
--------------------------------------------------------------------------
Steven Saner <ssaner at pantheranet.com>

From andy.saykao at staff.netspace.net.au  Tue Sep 29 02:45:19 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Tue, 29 Sep 2009 16:45:19 +1000
Subject: [c-nsp] Help with understanding AS5400
Message-ID: <56F211C5E3F24F47B103EA1B253822BE044AACBC@vic-cr-ex1.staff.netspace.net.au>

Hey All,
 
I'm new to all this voice stuff...
 
We've just installed a AS5400 and plugged the PRI's in but I'm not
seeing the interfaces below show up in the config. 
 
Eg: 
interface Serial6/0:15
interface Serial6/1:15
interface Serial6/2:15
interface Serial6/3:15

The Carrier is seeing alarms on their end so it could be that the PRI's
aren't properly activated yet. But regardless of this, am I suppose to
see those serial interfaces present in the config irrespective of
whether the PRIs are up or not?
 
When I try to manually add in the interface, it's not recognized.
 
as1-ks(config)#interface serial 6/0:15?
% Unrecognized command

Some more details about the AS...
 
as1-ks#sh ver
Cisco IOS Software, 5400 Software (C5400-IS-M), Version 12.4(11)T,
RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2006 by Cisco Systems, Inc.
Compiled Sun 19-Nov-06 00:33 by prod_rel_team
 
ROM: System Bootstrap, Version 12.1(2r)XD1, RELEASE SOFTWARE (fc1)
BOOTLDR: 5400 Software (C5400-BOOT-M), Version 12.1(5)T5,  RELEASE
SOFTWARE (fc1)
 
as1-ks-mel uptime is 40 minutes
System returned to ROM by reload at 15:53:14 AEST Tue Sep 29 2009
System restarted at 15:54:03 AEST Tue Sep 29 2009
System image file is "flash:c5400-is-mz.124-11.T.bin"
 
Cisco AS5400 (R7K) processor (revision T) with 262144K/65536K bytes of
memory.
Processor board ID JAB042904CY
R7000 CPU at 250MHz, Implementation 39, Rev 1.0, 256KB L2, 2048KB L3
Cache
Last reset from IOS reload
Manufacture Cookie Info:
 EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x31,
 Board Hardware Version 3.27, Item Number 800-5171-01,
 Board Revision B0, Serial Number JAB042904CY,
 PLD/ISP Version 2.2,  Manufacture Date 11-Jul-2000.
Processor 0x14, MAC Address 0001.42b3.5b7e
Backplane HW Revision 1.0, Flash Type 5V
2 FastEthernet interfaces
10 Serial interfaces
216 terminal lines
16 Channelized E1/PRI ports
512K bytes of NVRAM.
32768K bytes of processor board System flash (Read/Write)
8192K bytes of processor board Boot flash (Read/Write)
 
Configuration register is 0x2102

as1-ks#sh controllers e1 6/2
E1 6/2 is down.
  Applique type is Channelized E1 - balanced
  Far End Block Errors Detected
  Receiver has loss of signal.
  alarm-trigger is not set
  Version info of slot 6:  HW: 768, PLD Rev: 1
  Framer Version: 0x8

 
Thanks.
 
Andy

This email and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed. 
Please notify the sender immediately by email if you have received this 
email by mistake and delete this email from your system. 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 organisation. 
Finally, the recipient should check this email and any attachments for 
the presence of viruses. The organisation accepts no liability for any 
damage caused by any virus transmitted by this email.


From mtinka at globaltransit.net  Mon Sep 28 22:06:12 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Tue, 29 Sep 2009 10:06:12 +0800
Subject: [c-nsp] Pile on the 6509 noob
In-Reply-To: <d6966e4b0909280907n6b7400ecga9a0d59fc191c872@mail.gmail.com>
References: <C6E1121E.4FD6%cisco@peakpeak.com>
	<4AC0D5C1.9060901@fas.harvard.edu>
	<d6966e4b0909280907n6b7400ecga9a0d59fc191c872@mail.gmail.com>
Message-ID: <200909291006.14429.mtinka@globaltransit.net>

On Tuesday 29 September 2009 12:07:58 am Geoffrey Pendery 
wrote:

> If OC3 or bigger, 7206VXR's have worked great for us. 

Doubt there's anything larger than an OC-3 supported on the 
7200-VXR these days. IIRC, the OC-12 was discontinued a 
while back. But then again, Gig-E can be considered a WAN 
technology these days too :-).

> Pretty much all of these options will be cheaper, more
> robust, and better supported than FlexWAN,...

There's the SIP carrier cards now that probably offer better 
support than the FlexWAN, but have the price tag to prove it 
:-).

Cheers,

Mark.

From elmi at 4ever.de  Tue Sep 29 04:01:29 2009
From: elmi at 4ever.de (Elmar K. Bins)
Date: Tue, 29 Sep 2009 10:01:29 +0200
Subject: [c-nsp] Smartnet pricing?
In-Reply-To: <4AC1A18A.5030900@pantheranet.com>
References: <01d401ca407d$f1797900$d46c6b00$@com> <4AC19BE5.7040506@gmx.de>
	<4AC1A18A.5030900@pantheranet.com>
Message-ID: <20090929080129.GF37486@ronin.4ever.de>

Re Steven,

ssaner at pantheranet.com (Steven Saner) wrote:

>> for the time in between, why not go software-only SMARTnet? It even
>> contains config/TAC support (if ever required), full access to the
>> download area, and it's something like half of the regular SNT ... plus,
>> there's no logical reason to require a re-cert, as your hardware itself
>> isn't covered ...
> 
> Is this really available? I was asking a SmartNet rep about this once and 
> was led to believe this isn't an option. Maybe it wasn't then and is now? 
> Maybe they were pulling my leg?

As usual, with our last Cisco order I though "asking can't hurt" and did.
This is the first time our distributor offered us such a thing and at a
very good price (even if you have to buy three contracts for a smallish
ASR1002).

So yes, it seems to exist.

Elmar.

From jmayer at loplof.de  Tue Sep 29 03:38:31 2009
From: jmayer at loplof.de (Joerg Mayer)
Date: Tue, 29 Sep 2009 09:38:31 +0200
Subject: [c-nsp] So when is IPv6 failover coming to the ASA?
In-Reply-To: <20090928180226.GA24495@radiological.warningg.com>
References: <A47E89A512E4FF4492CA4DE10D7B7C900255E6077C@pscdalpexmb02.perotsystems.net>
	<20090928161248.GT7045@lboro.ac.uk>
	<A47E89A512E4FF4492CA4DE10D7B7C900255E60816@pscdalpexmb02.perotsystems.net>
	<4AC0F4A9.3010002@inex.ie> <20090928175143.GA8804@lboro.ac.uk>
	<20090928180226.GA24495@radiological.warningg.com>
Message-ID: <20090929073831.GF17910@thot.informatik.uni-kl.de>

On Mon, Sep 28, 2009 at 01:02:26PM -0500, Brandon Ewing wrote:
> 8.2 introduces "dual-service-object-group mode" -- meaning you can define a
> service group WITHOUT the protocol specifiction at the end, and define
> protocls on a per-service basis:
>
> object-group service TEST
>  service-object tcp-udp eq domain
>  service-object tcp eq www
>  service-object icmp echo

And this feature is present in 8.0.x already, just not documented and
not helped via '?' on the command line. asdm already uses it.

Ciao
 Joerg
--
Joerg Mayer                                           <jmayer at loplof.de>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.


From mcdonald.richards at gmail.com  Tue Sep 29 04:20:36 2009
From: mcdonald.richards at gmail.com (McDonald Richards)
Date: Tue, 29 Sep 2009 18:20:36 +1000
Subject: [c-nsp] Help with understanding AS5400
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AACBC@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE044AACBC@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <8bde567b0909290120w5f968de2yda2a640b704e2ee4@mail.gmail.com>

You need to tell the E1 controller it's to be used as a PRI and what
timeslots ie:

contr e1 6/0
 pri-group timeslots 1-31

This will create serial interface 6/0:15 and allow you to configure ISDN
parameters. Don't forget to set your framing on the controller either.

Macca


On Tue, Sep 29, 2009 at 4:45 PM, Andy Saykao <
andy.saykao at staff.netspace.net.au> wrote:

> Hey All,
>
> I'm new to all this voice stuff...
>
> We've just installed a AS5400 and plugged the PRI's in but I'm not
> seeing the interfaces below show up in the config.
>
> Eg:
> interface Serial6/0:15
> interface Serial6/1:15
> interface Serial6/2:15
> interface Serial6/3:15
>
> The Carrier is seeing alarms on their end so it could be that the PRI's
> aren't properly activated yet. But regardless of this, am I suppose to
> see those serial interfaces present in the config irrespective of
> whether the PRIs are up or not?
>
> When I try to manually add in the interface, it's not recognized.
>
> as1-ks(config)#interface serial 6/0:15?
> % Unrecognized command
>
> Some more details about the AS...
>
> as1-ks#sh ver
> Cisco IOS Software, 5400 Software (C5400-IS-M), Version 12.4(11)T,
> RELEASE SOFTWARE (fc2)
> Technical Support: http://www.cisco.com/techsupport
> Copyright (c) 1986-2006 by Cisco Systems, Inc.
> Compiled Sun 19-Nov-06 00:33 by prod_rel_team
>
> ROM: System Bootstrap, Version 12.1(2r)XD1, RELEASE SOFTWARE (fc1)
> BOOTLDR: 5400 Software (C5400-BOOT-M), Version 12.1(5)T5,  RELEASE
> SOFTWARE (fc1)
>
> as1-ks-mel uptime is 40 minutes
> System returned to ROM by reload at 15:53:14 AEST Tue Sep 29 2009
> System restarted at 15:54:03 AEST Tue Sep 29 2009
> System image file is "flash:c5400-is-mz.124-11.T.bin"
>
> Cisco AS5400 (R7K) processor (revision T) with 262144K/65536K bytes of
> memory.
> Processor board ID JAB042904CY
> R7000 CPU at 250MHz, Implementation 39, Rev 1.0, 256KB L2, 2048KB L3
> Cache
> Last reset from IOS reload
> Manufacture Cookie Info:
>  EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x31,
>  Board Hardware Version 3.27, Item Number 800-5171-01,
>  Board Revision B0, Serial Number JAB042904CY,
>  PLD/ISP Version 2.2,  Manufacture Date 11-Jul-2000.
> Processor 0x14, MAC Address 0001.42b3.5b7e
> Backplane HW Revision 1.0, Flash Type 5V
> 2 FastEthernet interfaces
> 10 Serial interfaces
> 216 terminal lines
> 16 Channelized E1/PRI ports
> 512K bytes of NVRAM.
> 32768K bytes of processor board System flash (Read/Write)
> 8192K bytes of processor board Boot flash (Read/Write)
>
> Configuration register is 0x2102
>
> as1-ks#sh controllers e1 6/2
> E1 6/2 is down.
>  Applique type is Channelized E1 - balanced
>  Far End Block Errors Detected
>  Receiver has loss of signal.
>  alarm-trigger is not set
>  Version info of slot 6:  HW: 768, PLD Rev: 1
>  Framer Version: 0x8
>
>
> Thanks.
>
> Andy
>
> This email and any files transmitted with it are confidential and intended
>  solely for the use of the individual or entity to whom they are addressed.
> Please notify the sender immediately by email if you have received this
> email by mistake and delete this email from your system. 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 organisation.
> Finally, the recipient should check this email and any attachments for
> the presence of viruses. The organisation accepts no liability for any
> damage caused by any virus transmitted by this email.
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From asturluismi at gmail.com  Tue Sep 29 04:24:37 2009
From: asturluismi at gmail.com (luismi)
Date: Tue, 29 Sep 2009 10:24:37 +0200
Subject: [c-nsp] Maybe Off.topic... VoIP wholesale carriers or just for
	south	america
Message-ID: <1254212677.7722.2.camel@dsba-ipso>

Hi,

This an off-topic issue, sorry about it.
I would like to know if you know some VoIP wholesale carriers or just
for south america.
Something like flowroute.com

Thanks in advance and sorry by this email again.


From dr at cluenet.de  Tue Sep 29 05:28:12 2009
From: dr at cluenet.de (Daniel Roesen)
Date: Tue, 29 Sep 2009 11:28:12 +0200
Subject: [c-nsp] Smartnet pricing?
In-Reply-To: <4AC1A18A.5030900@pantheranet.com>
References: <01d401ca407d$f1797900$d46c6b00$@com> <4AC19BE5.7040506@gmx.de>
	<4AC1A18A.5030900@pantheranet.com>
Message-ID: <20090929092812.GA23091@srv03.cluenet.de>

On Tue, Sep 29, 2009 at 12:56:26AM -0500, Steven Saner wrote:
> Is this really available? I was asking a SmartNet rep about this once and 
> was led to believe this isn't an option. Maybe it wasn't then and is now? 
> Maybe they were pulling my leg?

It does exist, CON-SW-..., but not listed in the GPL. When poking your
sales rep enough, they admit. :)

For pricing, see SP-SW-..., it's all the same as CON- (at least for all
products I checked, being various Catalyst and ASR1K parts). In fact,
the SP-SW- contract line brought me to CON-SW- when we asked for SP-SW-
offer and got told that SP- ain't sold in Europe, but there is
equivalent CON-SW- too... :)

Best regards,
Daniel


From Skeeve at eintellego.net  Tue Sep 29 05:28:45 2009
From: Skeeve at eintellego.net (Skeeve Stevens)
Date: Tue, 29 Sep 2009 19:28:45 +1000
Subject: [c-nsp] Bell Canada - Old Bogon?
Message-ID: <292AF25E62B8894C921B893B53A19D973957E7F66D@BUSINESSEX.business.ad>

Hey guys,

Could someone from Bell Canada who can deal with an old Bogon issue please contact me off list.

It is re: 180.x.x.x

...Skeeve

--
Skeeve Stevens, CEO/Technical Director
eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego.net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
www.linkedin.com/in/skeeve ; facebook.com/eintellego
--
NOC, NOC, who's there?

Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced.


From will at harg.net  Tue Sep 29 04:57:27 2009
From: will at harg.net (Will Hargrave)
Date: Tue, 29 Sep 2009 09:57:27 +0100
Subject: [c-nsp] Smartnet pricing?
In-Reply-To: <4AC1A18A.5030900@pantheranet.com>
References: <01d401ca407d$f1797900$d46c6b00$@com> <4AC19BE5.7040506@gmx.de>
	<4AC1A18A.5030900@pantheranet.com>
Message-ID: <4AC1CBF7.5060600@harg.net>

Steven Saner wrote:

> Is this really available? I was asking a SmartNet rep about this once
> and was led to believe this isn't an option. Maybe it wasn't then and is
> now? Maybe they were pulling my leg?

'SASU' - Software Application Support plus Upgrades

But last time I priced it up I got the same price for that as 8x5xNBD
hardware support, which was disappointing.

OP could go to a third party for support rather than Cisco, which should
reduce the cost yet still allow legitimate access to newer IOS.

From Skeeve at eintellego.net  Tue Sep 29 05:46:03 2009
From: Skeeve at eintellego.net (Skeeve Stevens)
Date: Tue, 29 Sep 2009 19:46:03 +1000
Subject: [c-nsp] Bell Canada - Old Bogon?
In-Reply-To: <292AF25E62B8894C921B893B53A19D973957E7F66D@BUSINESSEX.business.ad>
References: <292AF25E62B8894C921B893B53A19D973957E7F66D@BUSINESSEX.business.ad>
Message-ID: <292AF25E62B8894C921B893B53A19D973957E7F66F@BUSINESSEX.business.ad>

Why did I send this to cisco-nsp and not NANOG? Doh... sorry all.

--
Skeeve Stevens, CEO/Technical Director
eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego.net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
www.linkedin.com/in/skeeve ; facebook.com/eintellego
--
NOC, NOC, who's there?


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Skeeve Stevens
> Sent: Tuesday, 29 September 2009 7:29 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Bell Canada - Old Bogon?
> 
> Hey guys,
> 
> Could someone from Bell Canada who can deal with an old Bogon issue
> please contact me off list.
> 
> It is re: 180.x.x.x
> 
> ...Skeeve
> 
> --
> Skeeve Stevens, CEO/Technical Director
> eintellego Pty Ltd - The Networking Specialists
> skeeve at eintellego.net / www.eintellego.net
> Phone: 1300 753 383, Fax: (+612) 8572 9954
> Cell +61 (0)414 753 383 / skype://skeeve
> www.linkedin.com/in/skeeve ; facebook.com/eintellego
> --
> NOC, NOC, who's there?
> 
> Disclaimer: Limits of Liability and Disclaimer: This message is for the
> named person's use only. It may contain sensitive and private
> proprietary or legally privileged information. You must not, directly
> or indirectly, use, disclose, distribute, print, or copy any part of
> this message if you are not the intended recipient. eintellego Pty Ltd
> and each legal entity in the Tefilah Pty Ltd group of companies reserve
> the right to monitor all e-mail communications through its networks.
> Any views expressed in this message are those of the individual sender,
> except where the message states otherwise and the sender is authorised
> to state them to be the views of any such entity. Any reference to
> costs, fee quotations, contractual transactions and variations to
> contract terms is subject to separate confirmation in writing signed by
> an authorised representative of eintellego. Whilst all efforts are made
> to safeguard inbound and outbound e-mails, we cannot guarantee that
> attachments are!
>   virus-free or compatible with your systems and do not accept any
> liability in respect of viruses or computer problems experienced.
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From david.freedman at uk.clara.net  Tue Sep 29 06:05:08 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Tue, 29 Sep 2009 11:05:08 +0100
Subject: [c-nsp] Non-Java download option
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F96E2@zy-ex1.zyedge.local>
References: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F96E2@zy-ex1.zyedge.local>
Message-ID: <h9sm4k$p77$1@ger.gmane.org>

Still doesn't work for me, I can't even get that far, clicking on the
"download now" button as opposed to "add to cart" yields the ever popular:

"There was a problem retrieving your cart information due to application
error. Please contact applications support."

Seems to be something to do with opera, returning to my perl script.

Dave.


Ryan West wrote:
> You asked, now it's here.  You can leverage the download cart to queue up your downloads and get a page with all the URLs.  The main difference is now you have to accept the EULA, whereas with the bookmark or Stig's greasemonkey script, you did not.
> 
> -ryan 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


From nick at inex.ie  Tue Sep 29 07:09:57 2009
From: nick at inex.ie (Nick Hilliard)
Date: Tue, 29 Sep 2009 12:09:57 +0100
Subject: [c-nsp] ipv6 traffic layer2-switched netflow data export on c65k
In-Reply-To: <4A50CBF4.30007@inex.ie>
References: <4A50CBF4.30007@inex.ie>
Message-ID: <4AC1EB05.5090803@inex.ie>

On 05/07/2009 16:51, Nick Hilliard wrote:
> Is there anyone out there who has managed to get layer2 netflow data
> export working for l2 switched ipv6 traffic on a c65k? I've been beating
> my head against a wall trying to get it to work and just can't seem to.

hmmm, known limitation, it appears:

> http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/nde.html#wp1171043

which reads:

> ?The following IPv4 Netflow and NDE options are not available for IPv6 flows: [CSCek55571]
>
> ?Aggregation support (ip flow-aggregation cache command)
>
> ?Export of Layer 2 switched IPv6 flows
>
> ?Netflow and NDE sampling
>
> ?NDE filter support

While this documentation is for SR, the same limitation apparently applies 
to SX.  An internal documentation bug has been raised to get the 
limitations put into the SX train documentation, which doesn't currently 
note the problem:

> http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/nde.html

Nick

From jckdaniels12 at gmail.com  Tue Sep 29 07:46:28 2009
From: jckdaniels12 at gmail.com (jack daniels)
Date: Tue, 29 Sep 2009 17:16:28 +0530
Subject: [c-nsp] cisco 7206 VXR router
Message-ID: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>

 Dear group,

Please help me to identify 8 port Fast Ethernet Card for Cisco 7206 VXR
Router and how much Bandwidth points it will be occupy,
Cisco 7206 VXR (NPE-G1) 6 Slots VXR

Regards
J.Daniels

From zeusdadog at gmail.com  Tue Sep 29 08:02:11 2009
From: zeusdadog at gmail.com (Jay Nakamura)
Date: Tue, 29 Sep 2009 08:02:11 -0400
Subject: [c-nsp] cisco 7206 VXR router
In-Reply-To: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>
Message-ID: <9418aca70909290502s46916613y237e97ba8c2a37cc@mail.gmail.com>

Is there an 8 port FE card?  There is an 8 port 10BT card but I don't
know that there is an 8 port FE card...

This may help.

http://www.cisco.com/en/US/docs/routers/7200/configuration/7200_port_adapter_config_guidelines/3875In.html

On Tue, Sep 29, 2009 at 7:46 AM, jack daniels <jckdaniels12 at gmail.com> wrote:
> ?Dear group,
>
> Please help me to identify 8 port Fast Ethernet Card for Cisco 7206 VXR
> Router and how much Bandwidth points it will be occupy,
> Cisco 7206 VXR (NPE-G1) 6 Slots VXR
>
> Regards
> J.Daniels
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From amsoares at netcabo.pt  Tue Sep 29 08:03:54 2009
From: amsoares at netcabo.pt (Antonio Soares)
Date: Tue, 29 Sep 2009 13:03:54 +0100
Subject: [c-nsp] cisco 7206 VXR router
In-Reply-To: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>
Message-ID: <D7D03BBB2578483A9540F0B14D4B7B26@int.convex.pt>

Here's the document you need:

Cisco 7200 Bandwidth Points

http://www.cisco.com/en/US/products/hw/routers/ps341/prod_presentation_list.html

To add 8 FastEthernet Ports, you will need 4 * PA-2FE-TX. The NPE-G1 has 3 built-in GE interfaces.


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of jack daniels
Sent: ter?a-feira, 29 de Setembro de 2009 12:46
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] cisco 7206 VXR router


 Dear group,

Please help me to identify 8 port Fast Ethernet Card for Cisco 7206 VXR Router and how much Bandwidth points it will be occupy,
Cisco 7206 VXR (NPE-G1) 6 Slots VXR

Regards
J.Daniels
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



From dean at eatworms.org.uk  Tue Sep 29 08:09:36 2009
From: dean at eatworms.org.uk (Dean Smith)
Date: Tue, 29 Sep 2009 13:09:36 +0100
Subject: [c-nsp] cisco 7206 VXR router
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>
Message-ID: <F1EFC0B6698048E38639080A0A8CFD9A@experienbd1776>

Available port adaptors
http://www.cisco.com/en/US/products/hw/modules/ps2033/ps2546/index.html

Bandwidth points.
http://www.cisco.com/en/US/docs/routers/7200/configuration/7200_port_adapter_config_guidelines/3875In.html#wp1053970


----- Original Message ----- 
From: "jack daniels" <jckdaniels12 at gmail.com>
To: <cisco-nsp at puck.nether.net>
Sent: Tuesday, September 29, 2009 12:46 PM
Subject: [c-nsp] cisco 7206 VXR router


> Dear group,
>
> Please help me to identify 8 port Fast Ethernet Card for Cisco 7206 VXR
> Router and how much Bandwidth points it will be occupy,
> Cisco 7206 VXR (NPE-G1) 6 Slots VXR
>
> Regards
> J.Daniels
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> __________ NOD32 4466 (20090929) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
> 


From rens at autempspourmoi.be  Tue Sep 29 08:11:57 2009
From: rens at autempspourmoi.be (Rens)
Date: Tue, 29 Sep 2009 14:11:57 +0200
Subject: [c-nsp] cisco 7206 VXR router
In-Reply-To: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>
Message-ID: <4E4FE53B9B1E412E9D9242C9562734C7@EU.corp.clearwire.com>

I don't think any PA's exist with 8 FastE ports, only 8 Ethernet

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of jack daniels
Sent: mardi 29 septembre 2009 13:46
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] cisco 7206 VXR router

 Dear group,

Please help me to identify 8 port Fast Ethernet Card for Cisco 7206 VXR
Router and how much Bandwidth points it will be occupy,
Cisco 7206 VXR (NPE-G1) 6 Slots VXR

Regards
J.Daniels
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From david.freedman at uk.clara.net  Tue Sep 29 09:08:44 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Tue, 29 Sep 2009 14:08:44 +0100
Subject: [c-nsp] Another bughunt, this time VRF PBR
In-Reply-To: <h9r0n7$ha3$1@ger.gmane.org>
References: <7B8B0D6F623C3A40A0D0A80A66756E2B2C2F13@EXVS01.claranet.local>	<4AC02818.1020104@justinshore.com>	<7B8B0D6F623C3A40A0D0A80A66756E2B2C2F18@EXVS01.claranet.local>	<h9qv5v$c0i$1@ger.gmane.org>
	<h9r0n7$ha3$1@ger.gmane.org>
Message-ID: <h9t0ss$sl6$1@ger.gmane.org>

I can only now laugh at 12.4(24)T1 ,

*Sep 29 14:05:08.219: VT[Vi3]:Applying config commands on process
"VTEMPLATE Background Mgr" (187)
*Sep 29 14:05:08.219: VT[Vi3]:ip vrf receive TEST
*Sep 29 14:05:08.219: VT[Vi3]:no ip redirects
*Sep 29 14:05:08.219: VT[Vi3]:no ip unreachables
*Sep 29 14:05:08.223: VT[Vi3]:ip policy route-map TEST
*Sep 29 14:05:08.223: VT[Vi3]:no logging event link-status
*Sep 29 14:05:08.223: VT[Vi3]:no snmp trap link-status
*Sep 29 14:05:08.223: VT[Vi3]:end
*Sep 29 14:05:08.235: VT:Messages from (un)cloning Vi3:
% Need to enable Policy Based Routing on the interface first

completely ignoring the order I specified in radius (pbr first, vrf
receive second).

So that is three distinct bugs now, all in the latest releases. Shame.

Dave.


David Freedman wrote:
> Hah, SRD2a is even odder, refuses to even install the per-user vrf static!
> 
> This has however enabled me to home in on CSCsu33006 which sounds more
> likely, but it claims to be fixed in SRC4 and SRD which is annoying.
> 
> Dave.
> 
> 
> David Freedman wrote:
>> Have just tried with another live box running SRD (the original SRD) -
>> exactly the same story.
>>
>> Does anybody know if this is supported or not? I'm not seeing any
>> documentation which suggests it is not.
>>
>> David.
>>
>> David Freedman wrote:
>>> Yes, I woul absolutely love to, believe me :)
>>> Need to make sure nobody steps in at this point and claims that this is unsupported, if it is then am happy
>>> to move it to SR and away from 12.4(T) completely.
>>>
>>> ------------------------------------------------
>>> David Freedman
>>> Group Network Engineering 
>>> Claranet Limited
>>> http://www.clara.net
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Justin Shore [mailto:justin at justinshore.com]
>>> Sent: Mon 9/28/2009 04:06
>>> To: David Freedman
>>> Cc: cisco-nsp at puck.nether.net
>>> Subject: Re: [c-nsp] Another bughunt, this time VRF PBR
>>>  
>>> David Freedman wrote:
>>>> wonder if anybody has come across this before,
>>>>
>>>> in 12.4(15)T, configuring a virtual-access per-user such:
>>> I hate to suggest the obvious but since there are so many bugs in 
>>> 12.4(15)T have you considered bumping that to the latest minor rev?  I 
>>> think they're up to T7 or T8 now (must have been some bug list).
>>>
>>> Justin
>>>
>>>
>>>
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


From werner at trans.net  Tue Sep 29 07:56:25 2009
From: werner at trans.net (Detter Werner)
Date: Tue, 29 Sep 2009 13:56:25 +0200
Subject: [c-nsp] cisco 7206 VXR router
In-Reply-To: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>
Message-ID: <4AC1F5E9.4060502@trans.net>

Hi,

> Please help me to identify 8 port Fast Ethernet Card for Cisco 7206 VXR
> Router and how much Bandwidth points it will be occupy,
> Cisco 7206 VXR (NPE-G1) 6 Slots VXR

There is no 8-port Fast-Ethernet-Card for the 7206VXR, probably you mean
an 8-port Ethernet-Card (PA-8E) instead?

http://www.cisco.com/en/US/docs/routers/7200/configuration/7200_port_adapter_config_guidelines/3875In.html#wp1061974

Bye,
Werner


-- 
transnet Internet Services GmbH
Werner Detter - Netmaster

Lilienstr. 3-5 81669 M?nchen
http://www.trans.net
support at trans.net

From jckdaniels12 at gmail.com  Tue Sep 29 09:13:43 2009
From: jckdaniels12 at gmail.com (jack daniels)
Date: Tue, 29 Sep 2009 18:43:43 +0530
Subject: [c-nsp] cisco 7206 VXR router
In-Reply-To: <4AC1FEA7.8050301@thingy.com>
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>
	<D7D03BBB2578483A9540F0B14D4B7B26@int.convex.pt>
	<4AC1FEA7.8050301@thingy.com>
Message-ID: <8bb137f40909290613k1f82f19fs3649cca9785098c7@mail.gmail.com>

Hi ,

I'm a bit confused on -
"Also, don't assume that because you can add 8 100Mbit interfaces, that
you can use them at full speed.."

Regards



On Tue, Sep 29, 2009 at 6:03 PM, Howard Jones <howie at thingy.com> wrote:

> On 29/09/2009 13:03, Antonio Soares wrote:
> > Here's the document you need:
> >
> > Cisco 7200 Bandwidth Points
> >
> >
> http://www.cisco.com/en/US/products/hw/routers/ps341/prod_presentation_list.html
> >
> > To add 8 FastEthernet Ports, you will need 4 * PA-2FE-TX. The NPE-G1 has
> 3 built-in GE interfaces.
> >
> Also, don't assume that because you can add 8 100Mbit interfaces, that
> you can use them at full speed...
>

From jlewis at lewis.org  Tue Sep 29 09:30:44 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 29 Sep 2009 09:30:44 -0400 (EDT)
Subject: [c-nsp] cisco 7206 VXR router
In-Reply-To: <8bb137f40909290613k1f82f19fs3649cca9785098c7@mail.gmail.com>
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>
	<D7D03BBB2578483A9540F0B14D4B7B26@int.convex.pt>
	<4AC1FEA7.8050301@thingy.com>
	<8bb137f40909290613k1f82f19fs3649cca9785098c7@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0909290927400.22812@soloth.lewis.org>

On Tue, 29 Sep 2009, jack daniels wrote:

> I'm a bit confused on -
> "Also, don't assume that because you can add 8 100Mbit interfaces, that
> you can use them at full speed.."

A common issue with routers is that they have interfaces the processors 
can't keep up with.  i.e. a 2621 router has two built in 100baseT 
interfaces.  Try routing 100mbit/s of traffic through a 2621, and you'll 
be disappointed.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From markom at markom.info  Tue Sep 29 09:32:08 2009
From: markom at markom.info (Marko Milivojevic)
Date: Tue, 29 Sep 2009 13:32:08 +0000
Subject: [c-nsp] cisco 7206 VXR router
In-Reply-To: <8bb137f40909290613k1f82f19fs3649cca9785098c7@mail.gmail.com>
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com> 
	<D7D03BBB2578483A9540F0B14D4B7B26@int.convex.pt>
	<4AC1FEA7.8050301@thingy.com> 
	<8bb137f40909290613k1f82f19fs3649cca9785098c7@mail.gmail.com>
Message-ID: <d163b99c0909290632j7a2fd647p61329d25696860c5@mail.gmail.com>

On Tue, Sep 29, 2009 at 13:13, jack daniels <jckdaniels12 at gmail.com> wrote:
> I'm a bit confused on -
> "Also, don't assume that because you can add 8 100Mbit interfaces, that
> you can use them at full speed.."

NPE-G1 can't really pass more that 300-400 Mb/s of traffic without
experiencing serious CPU load.

--
Marko
CCIE #18427 (SP)
My network blog: http://cisco.markom.info/

From howie at thingy.com  Tue Sep 29 08:33:43 2009
From: howie at thingy.com (Howard Jones)
Date: Tue, 29 Sep 2009 13:33:43 +0100
Subject: [c-nsp] cisco 7206 VXR router
In-Reply-To: <D7D03BBB2578483A9540F0B14D4B7B26@int.convex.pt>
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>
	<D7D03BBB2578483A9540F0B14D4B7B26@int.convex.pt>
Message-ID: <4AC1FEA7.8050301@thingy.com>

On 29/09/2009 13:03, Antonio Soares wrote:
> Here's the document you need:
>
> Cisco 7200 Bandwidth Points
>
> http://www.cisco.com/en/US/products/hw/routers/ps341/prod_presentation_list.html
>
> To add 8 FastEthernet Ports, you will need 4 * PA-2FE-TX. The NPE-G1 has 3 built-in GE interfaces.
>   
Also, don't assume that because you can add 8 100Mbit interfaces, that
you can use them at full speed...

From werner at trans.net  Tue Sep 29 09:34:24 2009
From: werner at trans.net (Detter Werner)
Date: Tue, 29 Sep 2009 15:34:24 +0200
Subject: [c-nsp] cisco 7206 VXR router
In-Reply-To: <8bb137f40909290613k1f82f19fs3649cca9785098c7@mail.gmail.com>
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>	<D7D03BBB2578483A9540F0B14D4B7B26@int.convex.pt>	<4AC1FEA7.8050301@thingy.com>
	<8bb137f40909290613k1f82f19fs3649cca9785098c7@mail.gmail.com>
Message-ID: <4AC20CE0.6090501@trans.net>

Hi Jack,

you can't add eight 100Mbit-Interfaces additionally. The NPE-G1 has 3 build-in
Gbit-Ports, the 7206VXR chassis is able to handle 6 additional Cards.

One 100MBit FE-Card (PA-FE-TX/FX) allocates 200 Bandwith Points, a 2-Port
FE-Card (PA-2FE-TX/FX) allocates 400 BW-Points.

So, you probably have to buy four PA-2FE-TX/FX-Cards (if you cannot use
the build-in Gbit-Ports for your purposes *or* if you can use them buy
5 PA-FE-TX/FX-Cards :-)

Bye,
Werner

jack daniels schrieb:
> Hi ,
> 
> I'm a bit confused on -
> "Also, don't assume that because you can add 8 100Mbit interfaces, that
> you can use them at full speed.."
> 
> Regards
> 
> 
> 
> On Tue, Sep 29, 2009 at 6:03 PM, Howard Jones <howie at thingy.com> wrote:
> 
>> On 29/09/2009 13:03, Antonio Soares wrote:
>>> Here's the document you need:
>>>
>>> Cisco 7200 Bandwidth Points
>>>
>>>
>> http://www.cisco.com/en/US/products/hw/routers/ps341/prod_presentation_list.html
>>> To add 8 FastEthernet Ports, you will need 4 * PA-2FE-TX. The NPE-G1 has
>> 3 built-in GE interfaces.
>> Also, don't assume that because you can add 8 100Mbit interfaces, that
>> you can use them at full speed...
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


-- 
transnet Internet Services GmbH
Werner Detter - Netmaster

Lilienstr. 3-5 81669 M?nchen
http://www.trans.net
support at trans.net

From werner at trans.net  Tue Sep 29 09:51:45 2009
From: werner at trans.net (Detter Werner)
Date: Tue, 29 Sep 2009 15:51:45 +0200
Subject: [c-nsp] cisco 7206 VXR router
In-Reply-To: <4AC20CE0.6090501@trans.net>
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>	<D7D03BBB2578483A9540F0B14D4B7B26@int.convex.pt>	<4AC1FEA7.8050301@thingy.com>
	<8bb137f40909290613k1f82f19fs3649cca9785098c7@mail.gmail.com>
	<4AC20CE0.6090501@trans.net>
Message-ID: <4AC210F1.7010209@trans.net>

Hi again,

> So, you probably have to buy four PA-2FE-TX/FX-Cards (if you cannot use
> the build-in Gbit-Ports for your purposes *or* if you can use them buy
> 5 PA-FE-TX/FX-Cards :-)

Sorry, little mistake here: with four PA-2FE-Cards you'd exhaust the
Bandwith-Points.

For each PCI-Bus you can stick in 1xPA2-FE and 1xPA-FE then the maximum
for the PCI-Bus is reached (600 BP).

Bye,
Werner


-- 
transnet Internet Services GmbH
Werner Detter - Netmaster

Lilienstr. 3-5 81669 M?nchen
http://www.trans.net
support at trans.net

From justin at justinshore.com  Tue Sep 29 10:29:54 2009
From: justin at justinshore.com (Justin Shore)
Date: Tue, 29 Sep 2009 09:29:54 -0500
Subject: [c-nsp] Smartnet pricing?
In-Reply-To: <4AC1A18A.5030900@pantheranet.com>
References: <01d401ca407d$f1797900$d46c6b00$@com> <4AC19BE5.7040506@gmx.de>
	<4AC1A18A.5030900@pantheranet.com>
Message-ID: <4AC219E2.9060604@justinshore.com>

Steven Saner wrote:
> Is this really available? I was asking a SmartNet rep about this once 
> and was led to believe this isn't an option. Maybe it wasn't then and is 
> now? Maybe they were pulling my leg?

Sure.  For a 7206VXR the part number is SP-SW-7206VXRN.  However I don't 
generally recommend people buy it.  The software-only version doesn't 
come with any sort of hardware replacement.  For a wee bit more you can 
get the RTF SmartNet (SP-RR-7206VXRN).  That's Return To Factory 10-day 
turn around service.  That's what you should get if you're implementing 
a sparing strategy.  List on the SP-SW for a 7206VXR is $2688.  List on 
the SP-RR is only $2895.  So for a 7.7% increase in costs you can get a 
hardware replacement option.  8x5xNBD adds another $400 to the cost. 
24x7x4 is nearly double the SP-SW option.

The only time SP-SW makes sense is if you have an extremely large 
network and decent sparing strategy, where having a 1% hardware failure 
rate and eating the cost of the failed router (to replace it with a 
spare) costs you less than SP-RR coverage on all devices.  It's also 
good if you have a huge inventory of spares for a given model to back 
you up in case the covered unit shoots craps on you.

Personally I've taken my SP down the path of buying RTF coverage for 
everything that has a backup (hot or cold) and then putting either 
8x5xNBD (AR1) or 24x7x4 (AR3) on the devices that I don't have a good 
backup for.  The money saved was put towards buying more spares.  The 
collection of spares also gives me a lab to work in.  With those spares 
I can have a failed device replaced in an hour or two vs a minimum of 4 
hours plus however long it takes for TAC to decide that a RMA is needed.

Justin

From jihodges at zcorum.com  Tue Sep 29 10:32:37 2009
From: jihodges at zcorum.com (Jimmy Hodges)
Date: Tue, 29 Sep 2009 10:32:37 -0400
Subject: [c-nsp] Abnormal CPU usage on a G1 engine
Message-ID: <4AC21A85.5@zcorum.com>

Team,
    I have a G1 engine in a Cisco 7206VXR and another G1 engine in a 
7246VXR that are both showing almost 50% CPU usage on a network that 
only has 358 cable modems. I have other networks with over 3000 modems 
that don't create more than 25% CPU usage on their G1 engines. Everytime 
I check the "show proc cpu" output, it never shows any system processes 
consuming more than 5% of the CPU. Is there a process that I could be 
missing that is overworking both my G1 engines? Why is such a small 
network that passes 15 Mbps of traffic causing the CPU to work so hard? 
Any insight will be appreciated. Thanks again.

_*7206VXR GW:
*_Cisco IOS Software, 7200 Software (C7200-IPBASEK9-M), Version 
12.4(22)T, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Fri 10-Oct-08 10:10 by prod_rel_team

ROM: System Bootstrap, Version 12.3(4r)T1, RELEASE SOFTWARE (fc1)
BOOTLDR: 7200 Software (C7200-KBOOT-M), Version 12.3(15), RELEASE 
SOFTWARE (fc3)

Demopolis_GW uptime is 5 weeks, 5 days, 22 hours, 30 minutes
System returned to ROM by reload at 15:26:06 UTC Wed Aug 19 2009
System restarted at 10:28:39 CST Wed Aug 19 2009
System image file is "disk2:c7200-ipbasek9-mz.124-22.T.bin"
Last reload reason: Reload Command



This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be 
found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export at cisco.com.

Cisco 7206VXR (NPE-G1) processor (revision B) with 983040K/65536K bytes 
of memory.
Processor board ID 21302151
SB-1 CPU at 700MHz, Implementation 1025, Rev 0.2, 512KB L2 Cache
6 slot VXR midplane, Version 2.1

Last reset from power-on

PCI bus mb1 (Slots 1, 3 and 5) has a capacity of 600 bandwidth points.
Current configuration on bus mb1 has a total of 400 bandwidth points.
This configuration is within the PCI bus capacity and is supported.

PCI bus mb2 (Slots 2, 4 and 6) has a capacity of 600 bandwidth points.
Current configuration on bus mb2 has a total of 400 bandwidth points.
This configuration is within the PCI bus capacity and is supported.

Please refer to the following document "Cisco 7200 Series Port Adaptor
Hardware Configuration Guidelines" on Cisco.com <http://www.cisco.com>
for c7200 bandwidth points oversubscription and usage guidelines.


4 FastEthernet interfaces
3 Gigabit Ethernet interfaces
509K bytes of NVRAM.

500472K bytes of ATA PCMCIA card at slot 2 (Sector size 512 bytes).
16384K bytes of Flash internal SIMM (Sector size 256K).
Configuration register is 0x2102
--------------------------------------------------------------------------
08:59:05 AM Tuesday Sep 29 2009 CST



    444444444433333333333333366666333333333333333333333333333333
100
 90
 80
 70
 60
 50
 40
 30
 20
 10                          *****
   0....5....1....1....2....2....3....3....4....4....5....5....6
             0    5    0    5    0    5    0    5    0    5    0
               CPU% per second (last 60 seconds)


                  3
    633344333333335333334534333337343544333333333333433333333333
100
 90
 80
 70
 60
 50
 40               *
 30               *
 20               *
 10 *             #      *       *   *
   0....5....1....1....2....2....3....3....4....4....5....5....6
             0    5    0    5    0    5    0    5    0    5    0
               CPU% per minute (last 60 minutes)
              * = maximum CPU%   # = average CPU%


    233333223333333322323333332333322333232323333333333332333333322332223323
    663353984798075496685435438132378015517674758545776636566064498462545242
100
 90
 80
 70
 60
 50
 40  *  *    *** **   * *  *           *   *  **** *****  *** *     *   *
 30 ***************************************************************** * ** *
 20 ************************************************************************
 10 ************************************************************************
   0....5....1....1....2....2....3....3....4....4....5....5....6....6....7..
             0    5    0    5    0    5    0    5    0    5    0    5    0
                   CPU% per hour (last 72 hours)
                  * = maximum CPU%   # = average CPU%
---------------------------------------------------------------------------------------------------------
CPU utilization for five seconds: 3%/1%; one minute: 3%; five minutes: 3%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
  43    42455232   3538016      11999  1.27%  1.27%  1.27%   0 
Per-Second Jobs
 115        8356 870720560          0  0.15%  0.16%  0.15%   0 HQF 
Shaper Backg
  39     4245312   2357917       1800  0.23%  0.13%  0.12%   0 Net 
Background
   5     1654420    361374       4578  0.00%  0.03%  0.04%   0 Check heaps
  78         232      1375        168  0.00%  0.02%  0.00%   2 SSH Process
  71     1790924  18693365         95  0.07%  0.02%  0.00%   0 IP Input
 190       38280    385975         99  0.07%  0.00%  0.00%   0 SNMP ENGINE
 187        1444  35363326          0  0.07%  0.01%  0.00%   0 CCPROXY_CT
-------------------------------------------------------------------------------------
_*7246VXR:*_
08:54:14 AM Tuesday Sep 29 2009 CST



    4444444433333333336666688888555552222222222222222222222222
100
 90
 80
 70
 60
 50
 40
 30
 20
 10                   ***************                         **
   0....5....1....1....2....2....3....3....4....4....5....5....
             0    5    0    5    0    5    0    5    0    5
               CPU% per second (last 60 seconds)

    111 1 11131 11  21    11 1 1121     11     1 1 11111    11
    9364596660654644504455155397744566464843465965966675846546
100
 90
 80
 70
 60
 50
 40
 30          *      *
 20 * * * *****  *  *      *   ***       *     * * *****     * *
 10 #*# ***####*#*  #*  ***#*#*####*** *##   **#***#####* **## *
   0....5....1....1....2....2....3....3....4....4....5....5....
             0    5    0    5    0    5    0    5    0    5
               CPU% per minute (last 60 minutes)
              * = maximum CPU%   # = average CPU%

    3323223334434343333323333223233333233223333333333234332332223323334333
    0061465230020003211497053991833071642982019012104600509275866274230535
100
 90
 80
 70
 60
 50
 40       *  ** * *      * *        *         *        **   *   *     ** **
 30 **** *******************************************************************
 20 ************************************************************************
 10 ************##*****************************##***************************
   0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
             0    5    0    5    0    5    0    5    0    5    0    5    0
                   CPU% per hour (last 72 hours)
                  * = maximum CPU%   # = average CPU%
------------------------------------------------------------------------------------------------------
CPU utilization for five seconds: 3%/1%; one minute: 6%; five minutes: 5%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
 160    19589648  17773192       1102  0.79%  2.50%  2.59%   0 
polling_process
 175     1716008  13449246        127  0.00%  0.96%  0.28%   0 SNMP ENGINE
  89     1223000  22139911         55  0.07%  0.13%  0.12%   0 IP Input
  29      450260    487422        923  0.15%  0.09%  0.10%   0 Net 
Background
  44      676280  19603848         34  0.00%  0.34%  0.09%   0 MCU BPE 
IP Enque
 130      702788  14891015         47  0.00%  0.08%  0.08%   0 SNMP 
Proxy Forwa
  32        9044   1049043          8  0.00%  0.06%  0.07%   0 
Per-Second Jobs
   5      890092    138381       6432  0.00%  0.07%  0.06%   0 Check heaps
 174      459404  16156504         28  0.00%  0.05%  0.05%   0 PDU 
DISPATCHER
 173      307116  17539623         17  0.00%  0.04%  0.01%   0 IP SNMP
 127         144       188        765  0.15%  0.01%  0.00%   2 SSH Process
 178         264   1039788          0  0.00%  0.00%  0.00%   0 NTP
---------------------------------------------------------------------
Interface                       Cable 
Modem                               Description
            Total Reg   Oper  Unreg Offline Wideband initRC initD initIO 
initO
C4/0/U0     78    75    75    3     2       0        0      0     0      
0       C1******
C4/0/U1     47    46    46    1     1       0        0      0     0      
0       H1*******
C4/0/U2     58    58    58    0     0       0        0      0     0      
0       H2********
C4/0/U3     82    78    78    4     3       0        0      0     0      
0       C2********
C4/0/U4     37    35    35    2     2       0        0      0     0      
0       J*********
C4/0/U5     67    66    66    1     1       0        0      0     0      
0       P*******

Total:      369   358   358   11    9       0        0      0     0      0
----------------------------------------------------------------------------------
                              Cable Modem DOCSIS Version Summary

                  DOCSIS Registered    US QoS        US Phy Mode      DS 
Mode
                 -------------------  ---------  -------------------  
-------
Interface Online v3.0 v2.0 v1.1 v1.0  v1.1 v1.0  WB   scdm atdm tdma  
WB   NB
C4/0/U0   75     0    64   9    2     0    75    0    0    64   11    
0    75
C4/0/U1   46     0    41   5    0     0    46    0    0    41   5     
0    46
C4/0/U2   58     0    48   10   0     0    58    0    0    48   10    
0    58
C4/0/U3   78     0    61   13   4     0    78    0    0    61   17    
0    78
C4/0/U4   35     0    31   4    0     0    35    0    0    31   4     
0    35
C4/0/U5   66     0    60   6    0     0    66    0    0    60   6     
0    66

Total:    358    0    305  47   6     0    358   0    0    305  53    
0    358
------------------------------------------------------------------------
Vendor     OUI                   Cable Modem
                     Total Registered Unregistered Offline
00.14.E8   00.14.E8  17    17         0            0
00.15.2F   00.15.2F  12    12         0            0
00.15.9A   00.15.9A  7     7          0            0
00.16.B5   00.16.B5  3     3          0            0
00.17.EE   00.17.EE  77    75         2            2
00.18.C0   00.18.C0  78    74         4            4
00.19.5E   00.19.5E  11    10         1            1
00.1A.66   00.1A.66  2     2          0            0
00.1C.11   00.1C.11  4     4          0            0
00.23.74   00.23.74  17    17         0            0
Acterna    00.07.11  1     0          1            1
Belkin     00.30.54  46    46         0            0
Linksys    00.06.25  2     2          0            0
Linksys    00.13.10  1     0          1            1
Motorola   00.0E.5C  15    15         0            0
Motorola   00.0F.9F  3     3          0            0
Motorola   00.11.80  5     5          0            0
Motorola   00.11.AE  4     3          1            1
Motorola   00.12.25  6     6          0            0
Motorola   00.12.C9  21    21         0            0
Motorola   00.13.71  8     7          1            0
Motorola   00.14.04  27    27         0            0
SMC        00.04.E2  2     2          0            0

Total:               369   358        11           10
---------------------------------------------
Cisco Internetwork Operating System Software
IOS (tm) 7200 Software (UBR7200-IK9SU2-M), Version 12.3(23)BC8, RELEASE 
SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by cisco Systems, Inc.
Compiled Mon 06-Jul-09 12:05 by tinhuang
Image text-base: 0x60008EC4, data-base: 0x6189B8C0

ROM: System Bootstrap, Version 12.2(8r)B, RELEASE SOFTWARE (fc1)
BOOTLDR: 7200 Software (UBR7200-BOOT-M), Version 12.3(23)BC8, RELEASE 
SOFTWARE (fc1)

Demopolis_CMTS uptime is 1 week, 4 days, 20 hours, 4 minutes
System returned to ROM by power-on
System restarted at 12:50:37 CST Thu Sep 17 2009
System image file is "disk2:ubr7200-ik9su2-mz.123-23.BC8.bin"


This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be 
found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export at cisco.com.

cisco uBR7246VXR (UBR7200-NPE-G1) processor (revision A) with 
983040K/65536K bytes of memory.
Processor board ID SCA070200DU
SB-1 CPU at 700MHz, Implementation 1, Rev 0.2, 512KB L2 Cache
6 slot VXR midplane, Version 2.0

Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.

PCI bus mb1 has 200 bandwidth points
PCI bus mb2 has 242 bandwidth points

2 FastEthernet/IEEE 802.3 interface(s)
3 Gigabit Ethernet/IEEE 802.3 interface(s)
1 Cable Modem network interface(s)
509K bytes of non-volatile configuration memory.

250880K bytes of ATA PCMCIA card at slot 2 (Sector size 512 bytes).
16384K bytes of Flash internal SIMM (Sector size 256K).
Configuration register is 0x2102

-- 
Jimmy Hodges
Network Design Engineer
ZCorum ISP Alliance
jihodges at zcorum.com


From paul at paulstewart.org  Tue Sep 29 10:49:42 2009
From: paul at paulstewart.org (Paul Stewart)
Date: Tue, 29 Sep 2009 10:49:42 -0400
Subject: [c-nsp] Abnormal CPU usage on a G1 engine
In-Reply-To: <4AC21A85.5@zcorum.com>
References: <4AC21A85.5@zcorum.com>
Message-ID: <005c01ca4114$144136d0$3cc3a470$@org>

One thing I noticed is your T train release - there are MD (think that's the
new term) of software releases for the G1 engine.  I'd suggest looking at a
new IOS to see if that helps.

Also, there could be several configuration items that are causing this....
can you post a sanitized config?

Paul


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jimmy Hodges
Sent: September 29, 2009 10:33 AM
To: cisco-nsp at puck.nether.net
Cc: Tim Smith; dbertram at zcorum.com
Subject: [c-nsp] Abnormal CPU usage on a G1 engine

Team,
    I have a G1 engine in a Cisco 7206VXR and another G1 engine in a 
7246VXR that are both showing almost 50% CPU usage on a network that 
only has 358 cable modems. I have other networks with over 3000 modems 
that don't create more than 25% CPU usage on their G1 engines. Everytime 
I check the "show proc cpu" output, it never shows any system processes 
consuming more than 5% of the CPU. Is there a process that I could be 
missing that is overworking both my G1 engines? Why is such a small 
network that passes 15 Mbps of traffic causing the CPU to work so hard? 
Any insight will be appreciated. Thanks again.

_*7206VXR GW:
*_Cisco IOS Software, 7200 Software (C7200-IPBASEK9-M), Version 
12.4(22)T, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Fri 10-Oct-08 10:10 by prod_rel_team

ROM: System Bootstrap, Version 12.3(4r)T1, RELEASE SOFTWARE (fc1)
BOOTLDR: 7200 Software (C7200-KBOOT-M), Version 12.3(15), RELEASE 
SOFTWARE (fc3)

Demopolis_GW uptime is 5 weeks, 5 days, 22 hours, 30 minutes
System returned to ROM by reload at 15:26:06 UTC Wed Aug 19 2009
System restarted at 10:28:39 CST Wed Aug 19 2009
System image file is "disk2:c7200-ipbasek9-mz.124-22.T.bin"
Last reload reason: Reload Command



This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be 
found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export at cisco.com.

Cisco 7206VXR (NPE-G1) processor (revision B) with 983040K/65536K bytes 
of memory.
Processor board ID 21302151
SB-1 CPU at 700MHz, Implementation 1025, Rev 0.2, 512KB L2 Cache
6 slot VXR midplane, Version 2.1

Last reset from power-on

PCI bus mb1 (Slots 1, 3 and 5) has a capacity of 600 bandwidth points.
Current configuration on bus mb1 has a total of 400 bandwidth points.
This configuration is within the PCI bus capacity and is supported.

PCI bus mb2 (Slots 2, 4 and 6) has a capacity of 600 bandwidth points.
Current configuration on bus mb2 has a total of 400 bandwidth points.
This configuration is within the PCI bus capacity and is supported.

Please refer to the following document "Cisco 7200 Series Port Adaptor
Hardware Configuration Guidelines" on Cisco.com <http://www.cisco.com>
for c7200 bandwidth points oversubscription and usage guidelines.


4 FastEthernet interfaces
3 Gigabit Ethernet interfaces
509K bytes of NVRAM.

500472K bytes of ATA PCMCIA card at slot 2 (Sector size 512 bytes).
16384K bytes of Flash internal SIMM (Sector size 256K).
Configuration register is 0x2102
--------------------------------------------------------------------------
08:59:05 AM Tuesday Sep 29 2009 CST



    444444444433333333333333366666333333333333333333333333333333
100
 90
 80
 70
 60
 50
 40
 30
 20
 10                          *****
   0....5....1....1....2....2....3....3....4....4....5....5....6
             0    5    0    5    0    5    0    5    0    5    0
               CPU% per second (last 60 seconds)


                  3
    633344333333335333334534333337343544333333333333433333333333
100
 90
 80
 70
 60
 50
 40               *
 30               *
 20               *
 10 *             #      *       *   *
   0....5....1....1....2....2....3....3....4....4....5....5....6
             0    5    0    5    0    5    0    5    0    5    0
               CPU% per minute (last 60 minutes)
              * = maximum CPU%   # = average CPU%


    233333223333333322323333332333322333232323333333333332333333322332223323
    663353984798075496685435438132378015517674758545776636566064498462545242
100
 90
 80
 70
 60
 50
 40  *  *    *** **   * *  *           *   *  **** *****  *** *     *   *
 30 ***************************************************************** * ** *
 20 ************************************************************************
 10 ************************************************************************
   0....5....1....1....2....2....3....3....4....4....5....5....6....6....7..
             0    5    0    5    0    5    0    5    0    5    0    5    0
                   CPU% per hour (last 72 hours)
                  * = maximum CPU%   # = average CPU%
----------------------------------------------------------------------------
-----------------------------
CPU utilization for five seconds: 3%/1%; one minute: 3%; five minutes: 3%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
  43    42455232   3538016      11999  1.27%  1.27%  1.27%   0 
Per-Second Jobs
 115        8356 870720560          0  0.15%  0.16%  0.15%   0 HQF 
Shaper Backg
  39     4245312   2357917       1800  0.23%  0.13%  0.12%   0 Net 
Background
   5     1654420    361374       4578  0.00%  0.03%  0.04%   0 Check heaps
  78         232      1375        168  0.00%  0.02%  0.00%   2 SSH Process
  71     1790924  18693365         95  0.07%  0.02%  0.00%   0 IP Input
 190       38280    385975         99  0.07%  0.00%  0.00%   0 SNMP ENGINE
 187        1444  35363326          0  0.07%  0.01%  0.00%   0 CCPROXY_CT
----------------------------------------------------------------------------
---------
_*7246VXR:*_
08:54:14 AM Tuesday Sep 29 2009 CST



    4444444433333333336666688888555552222222222222222222222222
100
 90
 80
 70
 60
 50
 40
 30
 20
 10                   ***************                         **
   0....5....1....1....2....2....3....3....4....4....5....5....
             0    5    0    5    0    5    0    5    0    5
               CPU% per second (last 60 seconds)

    111 1 11131 11  21    11 1 1121     11     1 1 11111    11
    9364596660654644504455155397744566464843465965966675846546
100
 90
 80
 70
 60
 50
 40
 30          *      *
 20 * * * *****  *  *      *   ***       *     * * *****     * *
 10 #*# ***####*#*  #*  ***#*#*####*** *##   **#***#####* **## *
   0....5....1....1....2....2....3....3....4....4....5....5....
             0    5    0    5    0    5    0    5    0    5
               CPU% per minute (last 60 minutes)
              * = maximum CPU%   # = average CPU%

    3323223334434343333323333223233333233223333333333234332332223323334333
    0061465230020003211497053991833071642982019012104600509275866274230535
100
 90
 80
 70
 60
 50
 40       *  ** * *      * *        *         *        **   *   *     ** **
 30 **** *******************************************************************
 20 ************************************************************************
 10 ************##*****************************##***************************
   0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
             0    5    0    5    0    5    0    5    0    5    0    5    0
                   CPU% per hour (last 72 hours)
                  * = maximum CPU%   # = average CPU%
----------------------------------------------------------------------------
--------------------------
CPU utilization for five seconds: 3%/1%; one minute: 6%; five minutes: 5%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
 160    19589648  17773192       1102  0.79%  2.50%  2.59%   0 
polling_process
 175     1716008  13449246        127  0.00%  0.96%  0.28%   0 SNMP ENGINE
  89     1223000  22139911         55  0.07%  0.13%  0.12%   0 IP Input
  29      450260    487422        923  0.15%  0.09%  0.10%   0 Net 
Background
  44      676280  19603848         34  0.00%  0.34%  0.09%   0 MCU BPE 
IP Enque
 130      702788  14891015         47  0.00%  0.08%  0.08%   0 SNMP 
Proxy Forwa
  32        9044   1049043          8  0.00%  0.06%  0.07%   0 
Per-Second Jobs
   5      890092    138381       6432  0.00%  0.07%  0.06%   0 Check heaps
 174      459404  16156504         28  0.00%  0.05%  0.05%   0 PDU 
DISPATCHER
 173      307116  17539623         17  0.00%  0.04%  0.01%   0 IP SNMP
 127         144       188        765  0.15%  0.01%  0.00%   2 SSH Process
 178         264   1039788          0  0.00%  0.00%  0.00%   0 NTP
---------------------------------------------------------------------
Interface                       Cable 
Modem                               Description
            Total Reg   Oper  Unreg Offline Wideband initRC initD initIO 
initO
C4/0/U0     78    75    75    3     2       0        0      0     0      
0       C1******
C4/0/U1     47    46    46    1     1       0        0      0     0      
0       H1*******
C4/0/U2     58    58    58    0     0       0        0      0     0      
0       H2********
C4/0/U3     82    78    78    4     3       0        0      0     0      
0       C2********
C4/0/U4     37    35    35    2     2       0        0      0     0      
0       J*********
C4/0/U5     67    66    66    1     1       0        0      0     0      
0       P*******

Total:      369   358   358   11    9       0        0      0     0      0
----------------------------------------------------------------------------
------
                              Cable Modem DOCSIS Version Summary

                  DOCSIS Registered    US QoS        US Phy Mode      DS 
Mode
                 -------------------  ---------  -------------------  
-------
Interface Online v3.0 v2.0 v1.1 v1.0  v1.1 v1.0  WB   scdm atdm tdma  
WB   NB
C4/0/U0   75     0    64   9    2     0    75    0    0    64   11    
0    75
C4/0/U1   46     0    41   5    0     0    46    0    0    41   5     
0    46
C4/0/U2   58     0    48   10   0     0    58    0    0    48   10    
0    58
C4/0/U3   78     0    61   13   4     0    78    0    0    61   17    
0    78
C4/0/U4   35     0    31   4    0     0    35    0    0    31   4     
0    35
C4/0/U5   66     0    60   6    0     0    66    0    0    60   6     
0    66

Total:    358    0    305  47   6     0    358   0    0    305  53    
0    358
------------------------------------------------------------------------
Vendor     OUI                   Cable Modem
                     Total Registered Unregistered Offline
00.14.E8   00.14.E8  17    17         0            0
00.15.2F   00.15.2F  12    12         0            0
00.15.9A   00.15.9A  7     7          0            0
00.16.B5   00.16.B5  3     3          0            0
00.17.EE   00.17.EE  77    75         2            2
00.18.C0   00.18.C0  78    74         4            4
00.19.5E   00.19.5E  11    10         1            1
00.1A.66   00.1A.66  2     2          0            0
00.1C.11   00.1C.11  4     4          0            0
00.23.74   00.23.74  17    17         0            0
Acterna    00.07.11  1     0          1            1
Belkin     00.30.54  46    46         0            0
Linksys    00.06.25  2     2          0            0
Linksys    00.13.10  1     0          1            1
Motorola   00.0E.5C  15    15         0            0
Motorola   00.0F.9F  3     3          0            0
Motorola   00.11.80  5     5          0            0
Motorola   00.11.AE  4     3          1            1
Motorola   00.12.25  6     6          0            0
Motorola   00.12.C9  21    21         0            0
Motorola   00.13.71  8     7          1            0
Motorola   00.14.04  27    27         0            0
SMC        00.04.E2  2     2          0            0

Total:               369   358        11           10
---------------------------------------------
Cisco Internetwork Operating System Software
IOS (tm) 7200 Software (UBR7200-IK9SU2-M), Version 12.3(23)BC8, RELEASE 
SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by cisco Systems, Inc.
Compiled Mon 06-Jul-09 12:05 by tinhuang
Image text-base: 0x60008EC4, data-base: 0x6189B8C0

ROM: System Bootstrap, Version 12.2(8r)B, RELEASE SOFTWARE (fc1)
BOOTLDR: 7200 Software (UBR7200-BOOT-M), Version 12.3(23)BC8, RELEASE 
SOFTWARE (fc1)

Demopolis_CMTS uptime is 1 week, 4 days, 20 hours, 4 minutes
System returned to ROM by power-on
System restarted at 12:50:37 CST Thu Sep 17 2009
System image file is "disk2:ubr7200-ik9su2-mz.123-23.BC8.bin"


This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be 
found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export at cisco.com.

cisco uBR7246VXR (UBR7200-NPE-G1) processor (revision A) with 
983040K/65536K bytes of memory.
Processor board ID SCA070200DU
SB-1 CPU at 700MHz, Implementation 1, Rev 0.2, 512KB L2 Cache
6 slot VXR midplane, Version 2.0

Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.

PCI bus mb1 has 200 bandwidth points
PCI bus mb2 has 242 bandwidth points

2 FastEthernet/IEEE 802.3 interface(s)
3 Gigabit Ethernet/IEEE 802.3 interface(s)
1 Cable Modem network interface(s)
509K bytes of non-volatile configuration memory.

250880K bytes of ATA PCMCIA card at slot 2 (Sector size 512 bytes).
16384K bytes of Flash internal SIMM (Sector size 256K).
Configuration register is 0x2102

-- 
Jimmy Hodges
Network Design Engineer
ZCorum ISP Alliance
jihodges at zcorum.com

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From jay at west.net  Tue Sep 29 12:45:59 2009
From: jay at west.net (Jay Hennigan)
Date: Tue, 29 Sep 2009 09:45:59 -0700
Subject: [c-nsp] cisco 7206 VXR router
In-Reply-To: <4AC20CE0.6090501@trans.net>
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>	<D7D03BBB2578483A9540F0B14D4B7B26@int.convex.pt>	<4AC1FEA7.8050301@thingy.com>	<8bb137f40909290613k1f82f19fs3649cca9785098c7@mail.gmail.com>
	<4AC20CE0.6090501@trans.net>
Message-ID: <4AC239C7.7010005@west.net>

Detter Werner wrote:
> Hi Jack,
> 
> you can't add eight 100Mbit-Interfaces additionally. The NPE-G1 has 3 build-in
> Gbit-Ports, the 7206VXR chassis is able to handle 6 additional Cards.
> 
> One 100MBit FE-Card (PA-FE-TX/FX) allocates 200 Bandwith Points, a 2-Port
> FE-Card (PA-2FE-TX/FX) allocates 400 BW-Points.
> 
> So, you probably have to buy four PA-2FE-TX/FX-Cards (if you cannot use
> the build-in Gbit-Ports for your purposes *or* if you can use them buy
> 5 PA-FE-TX/FX-Cards :-)

I would buy a switch with at least one Gbit port and eight FE ports and 
trunk to VLANs.

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

From jihodges at zcorum.com  Tue Sep 29 13:01:13 2009
From: jihodges at zcorum.com (Jimmy Hodges)
Date: Tue, 29 Sep 2009 13:01:13 -0400
Subject: [c-nsp] Abnormal CPU usage on a G1 engine
In-Reply-To: <005c01ca4114$144136d0$3cc3a470$@org>
References: <4AC21A85.5@zcorum.com> <005c01ca4114$144136d0$3cc3a470$@org>
Message-ID: <4AC23D59.9010803@zcorum.com>

Paul Stewart wrote:
> One thing I noticed is your T train release - there are MD (think that's the
> new term) of software releases for the G1 engine.  I'd suggest looking at a
> new IOS to see if that helps.
>
> Also, there could be several configuration items that are causing this....
> can you post a sanitized config?
>
> Paul
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jimmy Hodges
> Sent: September 29, 2009 10:33 AM
> To: cisco-nsp at puck.nether.net
> Cc: Tim Smith; dbertram at zcorum.com
> Subject: [c-nsp] Abnormal CPU usage on a G1 engine
>
> Team,
>     I have a G1 engine in a Cisco 7206VXR and another G1 engine in a 
> 7246VXR that are both showing almost 50% CPU usage on a network that 
> only has 358 cable modems. I have other networks with over 3000 modems 
> that don't create more than 25% CPU usage on their G1 engines. Everytime 
> I check the "show proc cpu" output, it never shows any system processes 
> consuming more than 5% of the CPU. Is there a process that I could be 
> missing that is overworking both my G1 engines? Why is such a small 
> network that passes 15 Mbps of traffic causing the CPU to work so hard? 
> Any insight will be appreciated. Thanks again.
>
> _*7206VXR GW:
> *_Cisco IOS Software, 7200 Software (C7200-IPBASEK9-M), Version 
> 12.4(22)T, RELEASE SOFTWARE (fc1)
> Technical Support: http://www.cisco.com/techsupport
> Copyright (c) 1986-2008 by Cisco Systems, Inc.
> Compiled Fri 10-Oct-08 10:10 by prod_rel_team
>
> ROM: System Bootstrap, Version 12.3(4r)T1, RELEASE SOFTWARE (fc1)
> BOOTLDR: 7200 Software (C7200-KBOOT-M), Version 12.3(15), RELEASE 
> SOFTWARE (fc3)
>
> Demopolis_GW uptime is 5 weeks, 5 days, 22 hours, 30 minutes
> System returned to ROM by reload at 15:26:06 UTC Wed Aug 19 2009
> System restarted at 10:28:39 CST Wed Aug 19 2009
> System image file is "disk2:c7200-ipbasek9-mz.124-22.T.bin"
> Last reload reason: Reload Command
>
>
>
> This product contains cryptographic features and is subject to United
> States and local country laws governing import, export, transfer and
> use. Delivery of Cisco cryptographic products does not imply
> third-party authority to import, export, distribute or use encryption.
> Importers, exporters, distributors and users are responsible for
> compliance with U.S. and local country laws. By using this product you
> agree to comply with applicable laws and regulations. If you are unable
> to comply with U.S. and local laws, return this product immediately.
>
> A summary of U.S. laws governing Cisco cryptographic products may be 
> found at:
> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>
> If you require further assistance please contact us by sending email to
> export at cisco.com.
>
> Cisco 7206VXR (NPE-G1) processor (revision B) with 983040K/65536K bytes 
> of memory.
> Processor board ID 21302151
> SB-1 CPU at 700MHz, Implementation 1025, Rev 0.2, 512KB L2 Cache
> 6 slot VXR midplane, Version 2.1
>
> Last reset from power-on
>
> PCI bus mb1 (Slots 1, 3 and 5) has a capacity of 600 bandwidth points.
> Current configuration on bus mb1 has a total of 400 bandwidth points.
> This configuration is within the PCI bus capacity and is supported.
>
> PCI bus mb2 (Slots 2, 4 and 6) has a capacity of 600 bandwidth points.
> Current configuration on bus mb2 has a total of 400 bandwidth points.
> This configuration is within the PCI bus capacity and is supported.
>
> Please refer to the following document "Cisco 7200 Series Port Adaptor
> Hardware Configuration Guidelines" on Cisco.com <http://www.cisco.com>
> for c7200 bandwidth points oversubscription and usage guidelines.
>
>
> 4 FastEthernet interfaces
> 3 Gigabit Ethernet interfaces
> 509K bytes of NVRAM.
>
> 500472K bytes of ATA PCMCIA card at slot 2 (Sector size 512 bytes).
> 16384K bytes of Flash internal SIMM (Sector size 256K).
> Configuration register is 0x2102
> --------------------------------------------------------------------------
> 08:59:05 AM Tuesday Sep 29 2009 CST
>
>
>
>     444444444433333333333333366666333333333333333333333333333333
> 100
>  90
>  80
>  70
>  60
>  50
>  40
>  30
>  20
>  10                          *****
>    0....5....1....1....2....2....3....3....4....4....5....5....6
>              0    5    0    5    0    5    0    5    0    5    0
>                CPU% per second (last 60 seconds)
>
>
>                   3
>     633344333333335333334534333337343544333333333333433333333333
> 100
>  90
>  80
>  70
>  60
>  50
>  40               *
>  30               *
>  20               *
>  10 *             #      *       *   *
>    0....5....1....1....2....2....3....3....4....4....5....5....6
>              0    5    0    5    0    5    0    5    0    5    0
>                CPU% per minute (last 60 minutes)
>               * = maximum CPU%   # = average CPU%
>
>
>     233333223333333322323333332333322333232323333333333332333333322332223323
>     663353984798075496685435438132378015517674758545776636566064498462545242
> 100
>  90
>  80
>  70
>  60
>  50
>  40  *  *    *** **   * *  *           *   *  **** *****  *** *     *   *
>  30 ***************************************************************** * ** *
>  20 ************************************************************************
>  10 ************************************************************************
>    0....5....1....1....2....2....3....3....4....4....5....5....6....6....7..
>              0    5    0    5    0    5    0    5    0    5    0    5    0
>                    CPU% per hour (last 72 hours)
>                   * = maximum CPU%   # = average CPU%
> ----------------------------------------------------------------------------
> -----------------------------
> CPU utilization for five seconds: 3%/1%; one minute: 3%; five minutes: 3%
>  PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
>   43    42455232   3538016      11999  1.27%  1.27%  1.27%   0 
> Per-Second Jobs
>  115        8356 870720560          0  0.15%  0.16%  0.15%   0 HQF 
> Shaper Backg
>   39     4245312   2357917       1800  0.23%  0.13%  0.12%   0 Net 
> Background
>    5     1654420    361374       4578  0.00%  0.03%  0.04%   0 Check heaps
>   78         232      1375        168  0.00%  0.02%  0.00%   2 SSH Process
>   71     1790924  18693365         95  0.07%  0.02%  0.00%   0 IP Input
>  190       38280    385975         99  0.07%  0.00%  0.00%   0 SNMP ENGINE
>  187        1444  35363326          0  0.07%  0.01%  0.00%   0 CCPROXY_CT
> ----------------------------------------------------------------------------
> ---------
> _*7246VXR:*_
> 08:54:14 AM Tuesday Sep 29 2009 CST
>
>
>
>     4444444433333333336666688888555552222222222222222222222222
> 100
>  90
>  80
>  70
>  60
>  50
>  40
>  30
>  20
>  10                   ***************                         **
>    0....5....1....1....2....2....3....3....4....4....5....5....
>              0    5    0    5    0    5    0    5    0    5
>                CPU% per second (last 60 seconds)
>
>     111 1 11131 11  21    11 1 1121     11     1 1 11111    11
>     9364596660654644504455155397744566464843465965966675846546
> 100
>  90
>  80
>  70
>  60
>  50
>  40
>  30          *      *
>  20 * * * *****  *  *      *   ***       *     * * *****     * *
>  10 #*# ***####*#*  #*  ***#*#*####*** *##   **#***#####* **## *
>    0....5....1....1....2....2....3....3....4....4....5....5....
>              0    5    0    5    0    5    0    5    0    5
>                CPU% per minute (last 60 minutes)
>               * = maximum CPU%   # = average CPU%
>
>     3323223334434343333323333223233333233223333333333234332332223323334333
>     0061465230020003211497053991833071642982019012104600509275866274230535
> 100
>  90
>  80
>  70
>  60
>  50
>  40       *  ** * *      * *        *         *        **   *   *     ** **
>  30 **** *******************************************************************
>  20 ************************************************************************
>  10 ************##*****************************##***************************
>    0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
>              0    5    0    5    0    5    0    5    0    5    0    5    0
>                    CPU% per hour (last 72 hours)
>                   * = maximum CPU%   # = average CPU%
> ----------------------------------------------------------------------------
> --------------------------
> CPU utilization for five seconds: 3%/1%; one minute: 6%; five minutes: 5%
>  PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
>  160    19589648  17773192       1102  0.79%  2.50%  2.59%   0 
> polling_process
>  175     1716008  13449246        127  0.00%  0.96%  0.28%   0 SNMP ENGINE
>   89     1223000  22139911         55  0.07%  0.13%  0.12%   0 IP Input
>   29      450260    487422        923  0.15%  0.09%  0.10%   0 Net 
> Background
>   44      676280  19603848         34  0.00%  0.34%  0.09%   0 MCU BPE 
> IP Enque
>  130      702788  14891015         47  0.00%  0.08%  0.08%   0 SNMP 
> Proxy Forwa
>   32        9044   1049043          8  0.00%  0.06%  0.07%   0 
> Per-Second Jobs
>    5      890092    138381       6432  0.00%  0.07%  0.06%   0 Check heaps
>  174      459404  16156504         28  0.00%  0.05%  0.05%   0 PDU 
> DISPATCHER
>  173      307116  17539623         17  0.00%  0.04%  0.01%   0 IP SNMP
>  127         144       188        765  0.15%  0.01%  0.00%   2 SSH Process
>  178         264   1039788          0  0.00%  0.00%  0.00%   0 NTP
> ---------------------------------------------------------------------
> Interface                       Cable 
> Modem                               Description
>             Total Reg   Oper  Unreg Offline Wideband initRC initD initIO 
> initO
> C4/0/U0     78    75    75    3     2       0        0      0     0      
> 0       C1******
> C4/0/U1     47    46    46    1     1       0        0      0     0      
> 0       H1*******
> C4/0/U2     58    58    58    0     0       0        0      0     0      
> 0       H2********
> C4/0/U3     82    78    78    4     3       0        0      0     0      
> 0       C2********
> C4/0/U4     37    35    35    2     2       0        0      0     0      
> 0       J*********
> C4/0/U5     67    66    66    1     1       0        0      0     0      
> 0       P*******
>
> Total:      369   358   358   11    9       0        0      0     0      0
> ----------------------------------------------------------------------------
> ------
>                               Cable Modem DOCSIS Version Summary
>
>                   DOCSIS Registered    US QoS        US Phy Mode      DS 
> Mode
>                  -------------------  ---------  -------------------  
> -------
> Interface Online v3.0 v2.0 v1.1 v1.0  v1.1 v1.0  WB   scdm atdm tdma  
> WB   NB
> C4/0/U0   75     0    64   9    2     0    75    0    0    64   11    
> 0    75
> C4/0/U1   46     0    41   5    0     0    46    0    0    41   5     
> 0    46
> C4/0/U2   58     0    48   10   0     0    58    0    0    48   10    
> 0    58
> C4/0/U3   78     0    61   13   4     0    78    0    0    61   17    
> 0    78
> C4/0/U4   35     0    31   4    0     0    35    0    0    31   4     
> 0    35
> C4/0/U5   66     0    60   6    0     0    66    0    0    60   6     
> 0    66
>
> Total:    358    0    305  47   6     0    358   0    0    305  53    
> 0    358
> ------------------------------------------------------------------------
> Vendor     OUI                   Cable Modem
>                      Total Registered Unregistered Offline
> 00.14.E8   00.14.E8  17    17         0            0
> 00.15.2F   00.15.2F  12    12         0            0
> 00.15.9A   00.15.9A  7     7          0            0
> 00.16.B5   00.16.B5  3     3          0            0
> 00.17.EE   00.17.EE  77    75         2            2
> 00.18.C0   00.18.C0  78    74         4            4
> 00.19.5E   00.19.5E  11    10         1            1
> 00.1A.66   00.1A.66  2     2          0            0
> 00.1C.11   00.1C.11  4     4          0            0
> 00.23.74   00.23.74  17    17         0            0
> Acterna    00.07.11  1     0          1            1
> Belkin     00.30.54  46    46         0            0
> Linksys    00.06.25  2     2          0            0
> Linksys    00.13.10  1     0          1            1
> Motorola   00.0E.5C  15    15         0            0
> Motorola   00.0F.9F  3     3          0            0
> Motorola   00.11.80  5     5          0            0
> Motorola   00.11.AE  4     3          1            1
> Motorola   00.12.25  6     6          0            0
> Motorola   00.12.C9  21    21         0            0
> Motorola   00.13.71  8     7          1            0
> Motorola   00.14.04  27    27         0            0
> SMC        00.04.E2  2     2          0            0
>
> Total:               369   358        11           10
> ---------------------------------------------
> Cisco Internetwork Operating System Software
> IOS (tm) 7200 Software (UBR7200-IK9SU2-M), Version 12.3(23)BC8, RELEASE 
> SOFTWARE (fc1)
> Technical Support: http://www.cisco.com/techsupport
> Copyright (c) 1986-2009 by cisco Systems, Inc.
> Compiled Mon 06-Jul-09 12:05 by tinhuang
> Image text-base: 0x60008EC4, data-base: 0x6189B8C0
>
> ROM: System Bootstrap, Version 12.2(8r)B, RELEASE SOFTWARE (fc1)
> BOOTLDR: 7200 Software (UBR7200-BOOT-M), Version 12.3(23)BC8, RELEASE 
> SOFTWARE (fc1)
>
> Demopolis_CMTS uptime is 1 week, 4 days, 20 hours, 4 minutes
> System returned to ROM by power-on
> System restarted at 12:50:37 CST Thu Sep 17 2009
> System image file is "disk2:ubr7200-ik9su2-mz.123-23.BC8.bin"
>
>
> This product contains cryptographic features and is subject to United
> States and local country laws governing import, export, transfer and
> use. Delivery of Cisco cryptographic products does not imply
> third-party authority to import, export, distribute or use encryption.
> Importers, exporters, distributors and users are responsible for
> compliance with U.S. and local country laws. By using this product you
> agree to comply with applicable laws and regulations. If you are unable
> to comply with U.S. and local laws, return this product immediately.
>
> A summary of U.S. laws governing Cisco cryptographic products may be 
> found at:
> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>
> If you require further assistance please contact us by sending email to
> export at cisco.com.
>
> cisco uBR7246VXR (UBR7200-NPE-G1) processor (revision A) with 
> 983040K/65536K bytes of memory.
> Processor board ID SCA070200DU
> SB-1 CPU at 700MHz, Implementation 1, Rev 0.2, 512KB L2 Cache
> 6 slot VXR midplane, Version 2.0
>
> Last reset from power-on
> Bridging software.
> X.25 software, Version 3.0.0.
>
> PCI bus mb1 has 200 bandwidth points
> PCI bus mb2 has 242 bandwidth points
>
> 2 FastEthernet/IEEE 802.3 interface(s)
> 3 Gigabit Ethernet/IEEE 802.3 interface(s)
> 1 Cable Modem network interface(s)
> 509K bytes of non-volatile configuration memory.
>
> 250880K bytes of ATA PCMCIA card at slot 2 (Sector size 512 bytes).
> 16384K bytes of Flash internal SIMM (Sector size 256K).
> Configuration register is 0x2102
>
>   
Here you Paul. Thanks for your help!

upgrade fpd auto
version 12.4
service nagle
service timestamps debug datetime localtime show-timezone year
service timestamps log datetime localtime show-timezone year
service password-encryption
!
hostname ************
!
boot-start-marker
boot-end-marker
!
logging buffered 9192 informational
no logging console
enable password 0000000000000000
!
aaa new-model
!
!
aaa authentication login default local
!
!
aaa session-id common
clock timezone CST -6
clock summer-time CST recurring 2 Sun Mar 12:00 2 Sun Nov 12:00
ip source-route
ip cef
!
!
!
!
no ipv6 cef
multilink bundle-name authenticated
!
!
voice dsp waitstate 0
!
!
!
!
!
!
!
!
!
!
!
!
!
memory-size iomem 0
username **** password 00000000000
archive
 log config
  hidekeys
!
!
ip ssh port **** rotary 1
ip ssh rsa keypair-name ******
ip ssh version 2
!
class-map match-all Bank_Out
 match access-group 2
class-map match-all Bank_In
 match access-group 2
!
!
policy-map Bank_Inbound
 class Bank_In
   police cir 4500000
     conform-action transmit
     exceed-action drop
policy-map Bank_Outbound
 class Bank_Out
    police 4500000 32000 64000 conform-action transmit  exceed-action 
drop  violate-action drop
!
!
!
!
!
interface Loopback0
 ip address x.x.158.1 255.255.255.0 secondary
 ip address x.x.159.1 255.255.255.128 secondary
 ip address x.x.159.193 255.255.255.240 secondary
 ip address x.x.159.209 255.255.255.248 secondary
 ip address x.x.159.217 255.255.255.252
!
interface Tunnel11
 description ******
 ip address a.a.11.2 255.255.255.252
 ip flow ingress
 no ip route-cache cef
 no ip route-cache
 tunnel source x.x.159.241
 tunnel destination b.b.160.4
 tunnel checksum
!
interface GigabitEthernet0/1
 no ip address
 load-interval 30
 duplex full
 speed 100
 media-type rj45
 no negotiation auto
!
interface GigabitEthernet0/1.280
 description ************
 encapsulation dot1Q 280
 ip address c.c.237.234 255.255.255.252
 ip access-group ACL-WAN-In in
 ip access-group ACL-WAN-Out out
!
interface GigabitEthernet0/2
 description To LAN
 ip address x.x.159.225 255.255.255.240 secondary
 ip address x.x.159.241 255.255.255.248
 load-interval 30
 duplex auto
 speed auto
 media-type rj45
 no negotiation auto
!
interface GigabitEthernet0/3
 description Connection to **************
 ip address x.x.159.221 255.255.255.252
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 load-interval 30
 duplex auto
 speed auto
 media-type rj45
 no negotiation auto
 service-policy input Bank_Inbound
 service-policy output Bank_Outbound
!
interface FastEthernet3/0
 no ip address
 shutdown
 duplex half
!
interface FastEthernet4/0
 no ip address
 shutdown
 duplex half
!
interface FastEthernet5/0
 no ip address
 shutdown
 duplex half
!
interface FastEthernet6/0
 no ip address
 shutdown
 duplex half
!
no ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 c.c.237.233
ip route d.d.0.0 255.255.240.0 x.x.159.242 name ********
ip route b.b.161.26 255.255.255.255 Tunnel11 name ************
ip route b.b.176.48 255.255.255.240 Tunnel11 name ***********
ip route b.b.179.0 255.255.255.128 Tunnel11 name **********
ip route x.x.153.0 255.255.255.0 x.x.159.222 name BANK
ip route x.x.156.0 255.255.255.0 x.x.159.242 name CPE
ip route x.x.157.0 255.255.255.0 x.x.159.242 name CPE
ip route x.x.159.128 255.255.255.192 x.x.159.242 name CPE_Static's
no ip http server
no ip http secure-server
!
!
ip access-list extended ACL-WAN-In
 remark ********************************
 remark * ********* Inbound WAN ACL    *
 remark * Edited 09/01/2009 ***        *
 remark * This ACL for Inbound traffic *
 remark * on backbone interfaces       *
 remark **** Allow return traffic ******
 permit tcp any any established
 remark **** Allow access to ****
 permit ip any x.x.153.0 0.0.0.255
 remark **** ***************
 permit ip b.b.162.192 0.0.0.63 any
 permit ip b.b.163.32 0.0.0.31 any
 permit ip b.b.176.64 0.0.0.31 any
 permit ip b.b.178.0 0.0.0.15 any
 permit ip e.e.121.32 0.0.0.31 any
 permit ip host b.b.161.39 any
 remark **** Control ICMP ****
 permit icmp any any echo-reply
 permit icmp b.b.161.32 0.0.0.31 any
 permit icmp b.b.178.0 0.0.0.15 any
 permit icmp host b.b.173.39 any
 permit icmp host b.b.160.241 any
 permit icmp host b.b.172.39 any
 permit icmp host f.f.112.212 any
 deny   icmp any any
 remark ****Blocks Requested By Aff****
 deny   tcp any any range 1443 1444
 deny   udp any any range 1443 1444
 deny   tcp any any eq 62300
 deny   udp any any eq 62300
 deny   tcp any any eq 12437
 deny   udp any any eq 12437
 deny   tcp any any eq 24428
 deny   udp any any eq 24428
 deny   tcp any any eq 5386
 deny   udp any any eq 5386
 deny   tcp any any eq 11849
 deny   udp any any eq 11849
 deny   tcp any any eq 54069
 deny   udp any any eq 54069
 deny   ip host g.g.198.164 any
 remark **** MicroSoft Suspects ****
 deny   udp any any eq 135
 deny   tcp any any eq 135
 deny   udp any any eq netbios-ns
 deny   udp any any eq netbios-ss
 deny   tcp any any eq 138
 deny   udp any any eq netbios-dgm
 deny   tcp any any eq 139
 deny   tcp any any eq 445
 deny   udp any any eq 445
 deny   udp any any eq 593
 remark **** Trinoo Flood Attack ****
 deny   udp any any eq 13155
 deny   tcp any any eq 13155
 deny   udp any any eq 27765
 deny   tcp any any eq 27765
 deny   tcp any any eq 25532
 deny   udp any any eq 25532
 remark **** Slammer MS SQL ****
 deny   tcp any any range 1433 1434
 deny   udp any any range 1433 1434
 remark **** MYDOOM Ports ****
 deny   tcp any any range 3127 3198
 deny   udp any any range 3127 3198
 remark **** BackOrifice ****
 deny   udp any any eq 1349
 deny   tcp any any eq 1349
 deny   udp any any range 54320 54321
 deny   tcp any any range 54320 54321
 remark **** Sasser ****
 deny   tcp any any eq 5554
 remark **** SoBig ****
 deny   udp any any eq 8998
 remark **** Nachi ****
 deny   tcp any any eq 707
 remark **** Blaster ****
 deny   tcp any any eq 4444
 remark **** Deny private IP ****
 deny   ip 0.0.0.0 0.0.0.255 any
 deny   ip 10.0.0.0 0.0.0.255 any
 deny   ip 172.16.0.0 0.0.15.255 any
 deny   ip 192.168.0.0 0.0.0.255 any
 deny   ip 127.0.0.0 0.0.0.255 any
 remark **** Allow traffic ****
 permit ip any any
ip access-list extended ACL-WAN-Out
 remark *********************************
 remark * ********* Outbound WAN ACL    *
 remark * Edited 08/18/2009 ***         *
 remark * This ACL for Outbound traffic *
 remark * on backbone interfaces        *
 remark **** Allow return traffic ****
 permit tcp any any established
 remark ****Deny SMTP To ****
 deny   udp any host b.b.172.2 eq 25
 deny   tcp any host b.b.172.2 eq smtp
 remark **** ****
 permit ip any b.b.162.192 0.0.0.63
 permit ip any b.b.163.32 0.0.0.31
 permit ip any b.b.176.64 0.0.0.31
 permit ip any b.b.178.0 0.0.0.15
 permit ip any e.e.121.32 0.0.0.31
 permit ip any host b.b.161.39
 remark **** Deny private IP ****
 deny   ip 0.0.0.0 0.0.0.255 any
 deny   ip 10.0.0.0 0.0.0.255 any
 deny   ip 172.16.0.0 0.0.15.255 any
 deny   ip 192.168.0.0 0.0.0.255 any
 deny   ip 127.0.0.0 0.0.0.255 any
 remark **** Allow traffic ****
 permit ip any any
!
access-list 2 remark QOS Policy Matching for ALL TRAFFIC per interface
access-list 2 permit any
access-list compiled
snmp-server community a*********** RO
snmp-server community b************ RW
!
!
!
!
control-plane
!
!
!
mgcp fax t38 ecm
!
!
!
gatekeeper
 shutdown
!
banner motd 
***************************************************************************
                            NOTICE TO USERS


This computer system is the private property of ***********, whether
individual, corporate or government.  It is for authorized use only.
Users (authorized or unauthorized) have no explicit or implicit
expectation of privacy.

Any or all uses of this system and all files on this system may be
intercepted, monitored, recorded, copied, audited, inspected, and
disclosed to your employer, to authorized site, government, and law
enforcement personnel, as well as authorized officials of government
agencies, both domestic and foreign.

By using this system, the user consents to such interception, monitoring,
recording, copying, auditing, inspection, and disclosure at the
discretion of such personnel or officials.  Unauthorized or improper use
of this system may result in civil and criminal penalties and
administrative or disciplinary action, as appropriate. By continuing to
use this system you indicate your awareness of and consent to these terms
and conditions of use. LOG OFF IMMEDIATELY if you do not agree to the
conditions stated in this warning.

****************************************************************************

!
line con 0
 stopbits 1
line aux 0
 stopbits 1
line vty 0 4
 exec-timeout 60 0
 rotary 1
 transport preferred ssh
 transport input ssh
line vty 5 15
 exec-timeout 60 0
 rotary 1
 transport preferred ssh
 transport input ssh
!
ntp master
ntp update-calendar
ntp server h.h.34.1
end


-- 
Jimmy Hodges
Network Design Engineer
ZCorum ISP Alliance
jihodges at zcorum.com


From sforcejr at yahoo.com  Tue Sep 29 12:31:30 2009
From: sforcejr at yahoo.com (JA Colmenares)
Date: Tue, 29 Sep 2009 09:31:30 -0700 (PDT)
Subject: [c-nsp] Direct traffic from a tunnel to another tunnel
Message-ID: <540639.32790.qm@web110401.mail.gq1.yahoo.com>


CISCO Pix 506e 6.x
Cisco Pix 515?? 6.x
Location A
Location B
Main Office



I have the following
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?****MAIN OFFICE*****
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?INternet router
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Border Switch
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? |
?????????????Location A-ASA---------------Pix 506??????Pix 515-------------------Location B-ASA
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ?|
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? LAN-SWITCH(Layer 2 only)
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?LAN servers/Clients


There is a L2L tunnel from the 515 Pix (Main office) to another Pix in Location B.

There is another L2L?tunnel from Location A to Main Office in the 506e. My question is:

how do I route the traffic from 506 Tunnel from Location A to?515 Tunnel tocation B without adding any other device or hardware? 

What commands/settings would I need to modify in the?506 and the?515 to make this possible?

Thanks

John


      

From sethm at rollernet.us  Tue Sep 29 13:06:58 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 29 Sep 2009 10:06:58 -0700
Subject: [c-nsp] cisco 7206 VXR router
In-Reply-To: <Pine.LNX.4.61.0909290927400.22812@soloth.lewis.org>
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>	<D7D03BBB2578483A9540F0B14D4B7B26@int.convex.pt>	<4AC1FEA7.8050301@thingy.com>	<8bb137f40909290613k1f82f19fs3649cca9785098c7@mail.gmail.com>
	<Pine.LNX.4.61.0909290927400.22812@soloth.lewis.org>
Message-ID: <4AC23EB2.7080905@rollernet.us>

Jon Lewis wrote:
> On Tue, 29 Sep 2009, jack daniels wrote:
> 
>> I'm a bit confused on -
>> "Also, don't assume that because you can add 8 100Mbit interfaces, that
>> you can use them at full speed.."
> 
> A common issue with routers is that they have interfaces the processors
> can't keep up with.  i.e. a 2621 router has two built in 100baseT
> interfaces.  Try routing 100mbit/s of traffic through a 2621, and you'll
> be disappointed.
> 

2801 and 2811 have 10/100 ports, the 2821 has 1000/100/10 ports. Same
principle still applies though. ;)

~Seth

From gert at greenie.muc.de  Tue Sep 29 13:10:27 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 29 Sep 2009 19:10:27 +0200
Subject: [c-nsp] Smartnet pricing?
In-Reply-To: <4AC219E2.9060604@justinshore.com>
References: <01d401ca407d$f1797900$d46c6b00$@com> <4AC19BE5.7040506@gmx.de>
	<4AC1A18A.5030900@pantheranet.com>
	<4AC219E2.9060604@justinshore.com>
Message-ID: <20090929171027.GK1508@greenie.muc.de>

Hi,

On Tue, Sep 29, 2009 at 09:29:54AM -0500, Justin Shore wrote:
> Sure.  For a 7206VXR the part number is SP-SW-7206VXRN.  However I don't 
> generally recommend people buy it.  The software-only version doesn't 
> come with any sort of hardware replacement.  For a wee bit more you can 
> get the RTF SmartNet (SP-RR-7206VXRN).  That's Return To Factory 10-day 

How do people get these "part" numbers?  For our smartnet contracts, getting
the right numbers for various 6500+sup720 combinations seems to be nearly
impossible.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090929/55b1c8f0/attachment.bin>

From eninja at gmail.com  Tue Sep 29 14:20:21 2009
From: eninja at gmail.com (e ninja)
Date: Tue, 29 Sep 2009 11:20:21 -0700
Subject: [c-nsp] Smartnet pricing?
In-Reply-To: <01d401ca407d$f1797900$d46c6b00$@com>
References: <01d401ca407d$f1797900$d46c6b00$@com>
Message-ID: <e8590f60909291120i1e9ab0d3v335475f79cc334ac@mail.gmail.com>

Richey,

No it is not right.

   1. Anybody that has paid for software, should *never* have to pay for bug
   fixes. See http://resources.multiven.com/dossier-3
   2. Forcing people to pay for a service they haven't used is
extortion<http://en.wikipedia.org/wiki/Extortion>- a criminal act -
seek legal counsel

Bad things will continue to happen until good people take action. See what
happened when people protested about the inefficient download tool? It got
fixed.

Furthermore, there are alternatives to manufacturer network maintenance
services - a google search will reveal options.

We live in a free world, let's start acting as such.

Eninja :)



On Mon, Sep 28, 2009 at 1:54 PM, Richey <mylists at battleop.com> wrote:

> One of my customers called me today to ask me if this sounds right.  I
> don't
> much about smartnet but I told him I knew where to ask about this.    He
> said they let their initial smartnet contract expire about 5 years ago
> because they never used the support and management couldn't justify the
> cost.    Now they need a newer image because the current one they are using
> is buggy for whatever it is they are trying to do.     They contacted their
> "rep"  and the rep said Cisco wants them to pay for the last 5 years of
> smartnet plus however many going forward  in order to get the image.  They
> were quoted over $25k just to upgrade an image.   The part that sounds
> fishy
> is being forced to pay for 5 years of smartnet.   Does this sound right?
>
>
>
> Richey
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From gsgranados at comcast.net  Tue Sep 29 14:26:14 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Tue, 29 Sep 2009 11:26:14 -0700
Subject: [c-nsp] cisco 7206 VXR router
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>	<D7D03BBB2578483A9540F0B14D4B7B26@int.convex.pt>	<4AC1FEA7.8050301@thingy.com>	<8bb137f40909290613k1f82f19fs3649cca9785098c7@mail.gmail.com><Pine.LNX.4.61.0909290927400.22812@soloth.lewis.org>
	<4AC23EB2.7080905@rollernet.us>
Message-ID: <020501ca4132$5b3bdae0$2408120a@am.thmulti.com>

:)

> A common issue with routers is that they have interfaces the processors
> can't keep up with.  i.e. a 2621 router has two built in 100baseT

Better worded, a common issue with vendor C is that they have processors 
that the interfaces can't keep up with.  Other vendors including one that 
starts with a J have fewer issues in this area.;)

----- Original Message ----- 
From: "Seth Mattinen" <sethm at rollernet.us>
To: <cisco-nsp at puck.nether.net>
Sent: Tuesday, September 29, 2009 10:06 AM
Subject: Re: [c-nsp] cisco 7206 VXR router


> Jon Lewis wrote:
>> On Tue, 29 Sep 2009, jack daniels wrote:
>>
>>> I'm a bit confused on -
>>> "Also, don't assume that because you can add 8 100Mbit interfaces, that
>>> you can use them at full speed.."
>>
>> A common issue with routers is that they have interfaces the processors
>> can't keep up with.  i.e. a 2621 router has two built in 100baseT
>> interfaces.  Try routing 100mbit/s of traffic through a 2621, and you'll
>> be disappointed.
>>
>
> 2801 and 2811 have 10/100 ports, the 2821 has 1000/100/10 ports. Same
> principle still applies though. ;)
>
> ~Seth
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From djweis at internetsolver.com  Tue Sep 29 13:49:47 2009
From: djweis at internetsolver.com (Dave Weis)
Date: Tue, 29 Sep 2009 12:49:47 -0500 (CDT)
Subject: [c-nsp] Hardware for 'managed firewall'
Message-ID: <Pine.LNX.4.63.0909291238020.8252@charmed.internetsolver.com>


We want to provide a hosted/managed firewall service for our MPLS 
customers. Is a pair of ASA's with multiple contexts the best way to do 
this or would something else work better? I'm not concerned with the 
customers being able to make changes themselves.

Thanks
dave




-- 
Dave Weis
djweis at internetsolver.com
http://www.internetsolver.com/


From chris at chrisserafin.com  Tue Sep 29 15:07:15 2009
From: chris at chrisserafin.com (ChrisSerafin)
Date: Tue, 29 Sep 2009 14:07:15 -0500
Subject: [c-nsp] Hardware for 'managed firewall'
In-Reply-To: <Pine.LNX.4.63.0909291238020.8252@charmed.internetsolver.com>
References: <Pine.LNX.4.63.0909291238020.8252@charmed.internetsolver.com>
Message-ID: <4AC25AE3.5020207@chrisserafin.com>

I also believe you can do this with Junipers and Checkpoint VSX boxes


Dave Weis wrote:
>
> We want to provide a hosted/managed firewall service for our MPLS 
> customers. Is a pair of ASA's with multiple contexts the best way to 
> do this or would something else work better? I'm not concerned with 
> the customers being able to make changes themselves.
>
> Thanks
> dave
>
>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.409 / Virus Database: 270.13.114/2402 - Release Date: 09/29/09 05:54:00
>
>   


From jay at west.net  Tue Sep 29 15:39:51 2009
From: jay at west.net (Jay Hennigan)
Date: Tue, 29 Sep 2009 12:39:51 -0700
Subject: [c-nsp] cisco 7206 VXR router
In-Reply-To: <020501ca4132$5b3bdae0$2408120a@am.thmulti.com>
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>	<D7D03BBB2578483A9540F0B14D4B7B26@int.convex.pt>	<4AC1FEA7.8050301@thingy.com>	<8bb137f40909290613k1f82f19fs3649cca9785098c7@mail.gmail.com><Pine.LNX.4.61.0909290927400.22812@soloth.lewis.org>	<4AC23EB2.7080905@rollernet.us>
	<020501ca4132$5b3bdae0$2408120a@am.thmulti.com>
Message-ID: <4AC26287.5080906@west.net>

Scott Granados wrote:

> Better worded, a common issue with vendor C is that they have processors 
> that the interfaces can't keep up with.  Other vendors including one 
> that starts with a J have fewer issues in this area.;)

I think you have it bass-ackwards.  There are interfaces that the 
processors can't keep up with.

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

From justin at justinshore.com  Tue Sep 29 15:44:10 2009
From: justin at justinshore.com (Justin Shore)
Date: Tue, 29 Sep 2009 14:44:10 -0500
Subject: [c-nsp] Smartnet pricing?
In-Reply-To: <20090929171027.GK1508@greenie.muc.de>
References: <01d401ca407d$f1797900$d46c6b00$@com> <4AC19BE5.7040506@gmx.de>
	<4AC1A18A.5030900@pantheranet.com>
	<4AC219E2.9060604@justinshore.com>
	<20090929171027.GK1508@greenie.muc.de>
Message-ID: <4AC2638A.1000903@justinshore.com>

Gert Doering wrote:
> How do people get these "part" numbers?  For our smartnet contracts, getting
> the right numbers for various 6500+sup720 combinations seems to be nearly
> impossible.

Gert,

Two ways that I can think of.  The first is from the Global Price List 
on cisco.com:

https://tools.cisco.com/qtc/pricing/MainServlet

Or by way of the Dynamic Config Tool when you build a quote:

https://apps.cisco.com/qtc/config/jsp/configureHome.jsp

I'm assuming that all registered users have access to that information. 
  My CCO has several entitlements added to it so it's possible that 
other CCOs can't access the same data.  Your AM should be able to get 
the GPL added to your CCO though.

Justin



From nick at inex.ie  Tue Sep 29 16:01:54 2009
From: nick at inex.ie (Nick Hilliard)
Date: Tue, 29 Sep 2009 21:01:54 +0100
Subject: [c-nsp] Smartnet pricing?
In-Reply-To: <e8590f60909291120i1e9ab0d3v335475f79cc334ac@mail.gmail.com>
References: <01d401ca407d$f1797900$d46c6b00$@com>
	<e8590f60909291120i1e9ab0d3v335475f79cc334ac@mail.gmail.com>
Message-ID: <4AC267B2.2080609@inex.ie>

On 29/09/2009 19:20, e ninja wrote:
> No it is not right.
>
>     1. Anybody that has paid for software, should *never* have to pay for bug
>     fixes. See http://resources.multiven.com/dossier-3

That is an interesting wish-list.  Have you considered what it would do to 
the price of software if vendors were made liable?  I can't imagine the 
insurance premiums, and the gratuitous law suits.  Worse still, open source 
would be killed by it.  I know that if I were to be held liable, I wouldn't 
ever release anything or contribute anything to open source software.

>     2. Forcing people to pay for a service they haven't used is
> extortion<http://en.wikipedia.org/wiki/Extortion>- a criminal act -
> seek legal counsel

Legal counsel would probably argue that if you left your support 
subscription lapse and then attempted to renew it several years later, that 
the reason for doing so was because of some failure outside the 
manufacturer's control, and that you were pulling a fast one.

I'm not a lawyer.  Are you?

Nick

From alex at digriz.org.uk  Tue Sep 29 15:38:37 2009
From: alex at digriz.org.uk (Alexander Clouter)
Date: Tue, 29 Sep 2009 20:38:37 +0100
Subject: [c-nsp] Hardware for 'managed firewall'
References: <Pine.LNX.4.63.0909291238020.8252@charmed.internetsolver.com>
Message-ID: <ta4ap6-8h1.ln1@chipmunk.wormnet.eu>

Hi,

Dave Weis <djweis at internetsolver.com> wrote:
> 
> We want to provide a hosted/managed firewall service for our MPLS 
> customers. Is a pair of ASA's with multiple contexts the best way to do 
> this or would something else work better? I'm not concerned with the 
> customers being able to make changes themselves.
> 
No experience in actually doing this but I would say no.  :)

There is no (or it is so small I have missed it) sharing of object data 
between contexts and so you will find your self spending all your time 
trying to keep in sync the common parts of each context.

Instead you should apply simple RPF (if you do not have them already) 
rules so that all the IP traffic coming from your custom does come from 
their own allocated address space (prevent spoofing).

After you have done that, each customer can just be a raw IP range on 
whatever (single instance) firewall platform you wish to purchase making 
manglement of the whole thing just feel like a regular LAN.

Of course things get fun if you add multicast traffic and/or asymmetric 
routing :)

Cheers

-- 
Alexander Clouter
.sigmonster says: <ahzz_> i figured 17G oughta be enough.


From gsgranados at comcast.net  Tue Sep 29 16:09:07 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Tue, 29 Sep 2009 13:09:07 -0700
Subject: [c-nsp] cisco 7206 VXR router
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>	<D7D03BBB2578483A9540F0B14D4B7B26@int.convex.pt>	<4AC1FEA7.8050301@thingy.com>	<8bb137f40909290613k1f82f19fs3649cca9785098c7@mail.gmail.com><Pine.LNX.4.61.0909290927400.22812@soloth.lewis.org>	<4AC23EB2.7080905@rollernet.us><020501ca4132$5b3bdae0$2408120a@am.thmulti.com>
	<4AC26287.5080906@west.net>
Message-ID: <003d01ca4140$b91e8d20$2408120a@am.thmulti.com>

You're right, I was trying to express that the interfaces were able to out 
perform / to fast for the processor.  I.E. the 2621 example someone listed 
earlier.


----- Original Message ----- 
From: "Jay Hennigan" <jay at west.net>
To: <cisco-nsp at puck.nether.net>
Sent: Tuesday, September 29, 2009 12:39 PM
Subject: Re: [c-nsp] cisco 7206 VXR router


> Scott Granados wrote:
>
>> Better worded, a common issue with vendor C is that they have processors 
>> that the interfaces can't keep up with.  Other vendors including one that 
>> starts with a J have fewer issues in this area.;)
>
> I think you have it bass-ackwards.  There are interfaces that the 
> processors can't keep up with.
>
> --
> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
> Impulse Internet Service  -  http://www.impulse.net/
> Your local telephone and internet company - 805 884-6323 - WB6RDV
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From aseelye-lists at eltopia.com  Tue Sep 29 16:17:03 2009
From: aseelye-lists at eltopia.com (Aaron Seelye)
Date: Tue, 29 Sep 2009 13:17:03 -0700
Subject: [c-nsp] cisco 7206 VXR router
In-Reply-To: <4AC26287.5080906@west.net>
References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com>	<D7D03BBB2578483A9540F0B14D4B7B26@int.convex.pt>
	<4AC1FEA7.8050301@thingy.com>
	<8bb137f40909290613k1f82f19fs3649cca9785098c7@mail.gmail.com><Pine.LNX.4.61.0909290927400.22812@soloth.lewis.org>
	<4AC23EB2.7080905@rollernet.us><020501ca4132$5b3bdae0$2408120a@am.thmulti.com>
	<4AC26287.5080906@west.net>
Message-ID: <4AC26B3F.80006@eltopia.com>

Agreed, but I think he was pointing out the fact that it's not "routers" 
that have this problem, it's c-routers :).

-Aaron

Jay Hennigan wrote:
> Scott Granados wrote:
> 
>> Better worded, a common issue with vendor C is that they have 
>> processors that the interfaces can't keep up with.  Other vendors 
>> including one that starts with a J have fewer issues in this area.;)
> 
> I think you have it bass-ackwards.  There are interfaces that the 
> processors can't keep up with.
> 
> -- 
> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
> Impulse Internet Service  -  http://www.impulse.net/
> Your local telephone and internet company - 805 884-6323 - WB6RDV
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 
> ------------------------------------------------------------------------
> 
> 
> Internal Virus Database is out of date.
> Checked by AVG - www.avg.com 
> Version: 8.5.392 / Virus Database: 270.13.111/2386 - Release Date: 09/21/09 05:51:00
> 

From djweis at internetsolver.com  Tue Sep 29 17:08:40 2009
From: djweis at internetsolver.com (Dave Weis)
Date: Tue, 29 Sep 2009 16:08:40 -0500 (CDT)
Subject: [c-nsp] Hardware for 'managed firewall'
In-Reply-To: <4AC271C6.1090508@reachone.com>
References: <4AC271C6.1090508@reachone.com>
Message-ID: <Pine.LNX.4.63.0909291604180.17496@charmed.internetsolver.com>


On Tue, 29 Sep 2009, Christopher Hunt wrote:
>  As I painfully discovered, the Cisco ASA in Multiple Context mode does not 
> support IPSEC VPN clients nor L2TP3 tunnels ( 
> http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/ike.html 
> ), so choose your features carefully.  Eventually, we went with individual 
> [sets of] firewalls for each customer.

That's a pretty big omission! Any ETA to add that capability?

-- 
Dave Weis
djweis at internetsolver.com
http://www.internetsolver.com/


From chunt at reachone.com  Tue Sep 29 16:44:54 2009
From: chunt at reachone.com (Christopher Hunt)
Date: Tue, 29 Sep 2009 13:44:54 -0700
Subject: [c-nsp]  Hardware for 'managed firewall'
Message-ID: <4AC271C6.1090508@reachone.com>

Dave,
   As I painfully discovered, the Cisco ASA in Multiple Context mode 
does not support IPSEC VPN clients nor L2TP3 tunnels ( 
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/ike.html 
), so choose your features carefully.  Eventually, we went with 
individual [sets of] firewalls for each customer.

-- 
Christopher Hunt
ReachONE Internet, Inc.
(360)456-5640
www.reachone.com


------------------------------

Message: 5
Date: Tue, 29 Sep 2009 12:49:47 -0500 (CDT)
From: Dave Weis <djweis at internetsolver.com>
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Hardware for 'managed firewall'
Message-ID:
	<Pine.LNX.4.63.0909291238020.8252 at charmed.internetsolver.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed


We want to provide a hosted/managed firewall service for our MPLS 
customers. Is a pair of ASA's with multiple contexts the best way to do 
this or would something else work better? I'm not concerned with the 
customers being able to make changes themselves.

Thanks
dave




-- 
Dave Weis
djweis at internetsolver.com
http://www.internetsolver.com/




From justin at justinshore.com  Tue Sep 29 17:57:58 2009
From: justin at justinshore.com (Justin Shore)
Date: Tue, 29 Sep 2009 16:57:58 -0500
Subject: [c-nsp] Hardware for 'managed firewall'
In-Reply-To: <Pine.LNX.4.63.0909291238020.8252@charmed.internetsolver.com>
References: <Pine.LNX.4.63.0909291238020.8252@charmed.internetsolver.com>
Message-ID: <4AC282E6.7070805@justinshore.com>

Dave Weis wrote:
> 
> We want to provide a hosted/managed firewall service for our MPLS 
> customers. Is a pair of ASA's with multiple contexts the best way to do 
> this or would something else work better? I'm not concerned with the 
> customers being able to make changes themselves.

We do this with a pair of FWSMs in a pair of 7600s.  Customers in our 
data center reside in MPLS/VPNs.  The FWSMs upstream in the network are 
their ticket out of the MPLS/VPN and out to the Internet.  Each customer 
is in their own context.  Not too difficult.

We could have done this with ASAs but they do not scale as well.  If you 
want to start cheaply then yes you can use ASAs but research their 
limitations (especially, # of context and throughput vs price).  Also be 
sure that you understand that you can not use VPN on a ASA with multiple 
contexts.  If you need to terminate VPN services (L2L or client) and put 
them into isolated customer environments on the secured side of the 
network then you need to look into a router-based platform.

So you know, no Cisco firewalls are MPLS-aware; that includes the FWSM. 
  However you don't really need it since you only need to map VLANs to 
it.  The VLANs themselves can be in the necessary VRF, thus making that 
context partially in that VRF.  ie, VLAN 100 is in the 
privately-addressed customer VRF and is assigned to the context and used 
as the "inside" interface.  VLAN 200 is publicly-addressed, not in a 
defined VRF (default VRF or wherever you keep your public Internet at), 
is assigned to the context and is used as the "outside" interface.  The 
customer can manage their own context if they want but we don't yet have 
any that do this.  You could let customers bring their own FW if they 
want by mapping the inside and outside VLANs to switchports in your data 
center (one on the public side and one in the customer VRF) and letting 
the users use those.

Justin



From omar.parihuana at gmail.com  Tue Sep 29 18:23:30 2009
From: omar.parihuana at gmail.com (omar parihuana)
Date: Tue, 29 Sep 2009 17:23:30 -0500
Subject: [c-nsp] OT: Router//Switches Hardware inventory
Message-ID: <834c50110909291523o7020f1edq66a8b610b77fe6d6@mail.gmail.com>

Hello List,

Do you know an open source tool for router hardware inventory? I have many
Cisco devices with many cards inserted, and manage the inventory via Excel
Format is hard... please any suggestion?

Rgds.

-- 
Omar E.P.T
-----------------
Certified Networking Professionals make better Connections!

From A.L.M.Buxey at lboro.ac.uk  Tue Sep 29 18:42:42 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Tue, 29 Sep 2009 23:42:42 +0100
Subject: [c-nsp] OT: Router//Switches Hardware inventory
In-Reply-To: <834c50110909291523o7020f1edq66a8b610b77fe6d6@mail.gmail.com>
References: <834c50110909291523o7020f1edq66a8b610b77fe6d6@mail.gmail.com>
Message-ID: <20090929224242.GC13752@lboro.ac.uk>

Hi,

> Do you know an open source tool for router hardware inventory? I have many
> Cisco devices with many cards inserted, and manage the inventory via Excel
> Format is hard... please any suggestion?

RANCID is pretty good at pulling the details out. you can then 
look through the resulting files for eg serial numbers , part
numbers etc. beware - its command line stuff - though you can add
a webified system with a web based CVS tool, for example.

alan

From nick at inex.ie  Tue Sep 29 18:50:44 2009
From: nick at inex.ie (Nick Hilliard)
Date: Tue, 29 Sep 2009 23:50:44 +0100
Subject: [c-nsp] OT: Router//Switches Hardware inventory
In-Reply-To: <834c50110909291523o7020f1edq66a8b610b77fe6d6@mail.gmail.com>
References: <834c50110909291523o7020f1edq66a8b610b77fe6d6@mail.gmail.com>
Message-ID: <4AC28F44.3040903@inex.ie>

On 29/09/2009 23:23, omar parihuana wrote:
> Do you know an open source tool for router hardware inventory? I have many
> Cisco devices with many cards inserted, and manage the inventory via Excel
> Format is hard... please any suggestion?

RANCID (http://www.shrubbery.net/rancid/) will manage version control for 
your router configurations, but at the top of each configuration file, it 
will also attempt to do a semi-intelligent internal inventory of the 
router, down to blade level.  The down-side is that the configuration is 
stored in unstructured text.

If you want something which gives structured text, use "show inventory" on 
your equipment.  The output of this command can be parsed, and if you're 
running rancid or something similar which allows scripted access to your 
kit, you can script this to provide structured lists of equipment.

Nick

From lmeade at signal.ca  Tue Sep 29 19:31:36 2009
From: lmeade at signal.ca (Leslie Meade)
Date: Tue, 29 Sep 2009 16:31:36 -0700
Subject: [c-nsp] moving to Zone Based Firewall
Message-ID: <EAF4FF4AB2142D499F2F5A3B9D851529051AC97B@exch-bo.MGVFS.McLeanNet>

I have an 1811 with an old cfg on it. I  want to update it to use zone based rules. 
However the SDM is telling me that the legacy firewall is in place, and I need to remove them. 
I am a security and routing newbie. Can someone point me in the right direction ? 
I have attached the relevant parts. I cannot shut the router down or remove it to work on it

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1811.txt
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090929/86a1b2c1/attachment-0001.txt>

From david at hughes.com.au  Tue Sep 29 19:05:34 2009
From: david at hughes.com.au (David Hughes)
Date: Wed, 30 Sep 2009 09:05:34 +1000
Subject: [c-nsp] Hardware for 'managed firewall'
In-Reply-To: <Pine.LNX.4.63.0909291604180.17496@charmed.internetsolver.com>
References: <4AC271C6.1090508@reachone.com>
	<Pine.LNX.4.63.0909291604180.17496@charmed.internetsolver.com>
Message-ID: <F48AF478-5AAD-495C-AAB2-409C132EA8F2@hughes.com.au>


On 30/09/2009, at 7:08 AM, Dave Weis wrote:

>
> On Tue, 29 Sep 2009, Christopher Hunt wrote:
>> As I painfully discovered, the Cisco ASA in Multiple Context mode  
>> does not support IPSEC VPN clients nor L2TP3 tunnels
>
> That's a pretty big omission! Any ETA to add that capability?


Yeah, they've never supported VPN in multi-context mode.  Major pain.   
And if you are a dense hosting provider the 50 context limit (and  
limited performance) of a 5540 for example doesn't work too well.   
These issues made us look around again and J-Vendor's boxes are making  
the ASA's look a bit ordinary.


David
...

From chip.gwyn at gmail.com  Tue Sep 29 20:45:57 2009
From: chip.gwyn at gmail.com (chip)
Date: Tue, 29 Sep 2009 20:45:57 -0400
Subject: [c-nsp] OT: Router//Switches Hardware inventory
In-Reply-To: <4AC28F44.3040903@inex.ie>
References: <834c50110909291523o7020f1edq66a8b610b77fe6d6@mail.gmail.com>
	<4AC28F44.3040903@inex.ie>
Message-ID: <64a8ad980909291745w2d1ab70p3bc98aeeb10bd3ac@mail.gmail.com>

On Tue, Sep 29, 2009 at 6:50 PM, Nick Hilliard <nick at inex.ie> wrote:

> On 29/09/2009 23:23, omar parihuana wrote:
>
>> Do you know an open source tool for router hardware inventory? I have many
>> Cisco devices with many cards inserted, and manage the inventory via Excel
>> Format is hard... please any suggestion?
>>
>
> RANCID (http://www.shrubbery.net/rancid/) will manage version control for
> your router configurations, but at the top of each configuration file, it
> will also attempt to do a semi-intelligent internal inventory of the router,
> down to blade level.  The down-side is that the configuration is stored in
> unstructured text.
>
> If you want something which gives structured text, use "show inventory" on
> your equipment.  The output of this command can be parsed, and if you're
> running rancid or something similar which allows scripted access to your
> kit, you can script this to provide structured lists of equipment.
>
> Nick
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


There's also a 'show inventory raw'...for what it's worth


-- 
Just my $.02, your mileage may vary,  batteries not included, etc....

From SHughes at GREnergy.com  Tue Sep 29 20:54:58 2009
From: SHughes at GREnergy.com (Hughes, Scott GRE/MG)
Date: Tue, 29 Sep 2009 19:54:58 -0500
Subject: [c-nsp] OT: Router//Switches Hardware inventory
In-Reply-To: <834c50110909291523o7020f1edq66a8b610b77fe6d6@mail.gmail.com>
References: <834c50110909291523o7020f1edq66a8b610b77fe6d6@mail.gmail.com>
Message-ID: <A1A9EA98-B946-4C97-A9CC-7E20527058AC@GREnergy.com>

Netdisco does a tremendous job of hardware inventory. It discovers new  
devices via CDP and stores it's data in a database. It knows about  
blades, wics, and NM modules (with serial numbers for all)

http://www.netdisco.org

Sent from my iPhone.

On Sep 29, 2009, at 5:39 PM, "omar parihuana"  
<omar.parihuana at gmail.com> wrote:

> Hello List,
>
> Do you know an open source tool for router hardware inventory? I  
> have many
> Cisco devices with many cards inserted, and manage the inventory via  
> Excel
> Format is hard... please any suggestion?
>
> Rgds.
>
> -- 
> Omar E.P.T
> -----------------
> Certified Networking Professionals make better Connections!
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
NOTICE TO RECIPIENT: The information contained in this message from
Great River Energy and any attachments are confidential and intended
only for the named recipient(s). If you have received this message in 
error, you are prohibited from copying, distributing or using the
information. Please contact the sender immediately by return email and
delete the original message.


 


From djweis at internetsolver.com  Tue Sep 29 23:23:51 2009
From: djweis at internetsolver.com (Dave Weis)
Date: Tue, 29 Sep 2009 22:23:51 -0500 (CDT)
Subject: [c-nsp] Hardware for 'managed firewall'
In-Reply-To: <F48AF478-5AAD-495C-AAB2-409C132EA8F2@hughes.com.au>
References: <4AC271C6.1090508@reachone.com>
	<Pine.LNX.4.63.0909291604180.17496@charmed.internetsolver.com>
	<F48AF478-5AAD-495C-AAB2-409C132EA8F2@hughes.com.au>
Message-ID: <Pine.LNX.4.63.0909292220430.28960@charmed.internetsolver.com>


On Wed, 30 Sep 2009, David Hughes wrote:
> On 30/09/2009, at 7:08 AM, Dave Weis wrote:
>> On Tue, 29 Sep 2009, Christopher Hunt wrote:
>>> As I painfully discovered, the Cisco ASA in Multiple Context mode does not 
>>> support IPSEC VPN clients nor L2TP3 tunnels
>> 
>> That's a pretty big omission! Any ETA to add that capability?
> Yeah, they've never supported VPN in multi-context mode.  Major pain.  And if 
> you are a dense hosting provider the 50 context limit (and limited 
> performance) of a 5540 for example doesn't work too well.  These issues made 
> us look around again and J-Vendor's boxes are making the ASA's look a bit 
> ordinary.

I never enjoyed working on the netscreens. I suppose if each virtual 
firewall customer could get the same awkward web interface for self 
provisioning it could be made to work.

-- 
Dave Weis
djweis at internetsolver.com
http://www.internetsolver.com/


From christian at automatick.net  Tue Sep 29 23:34:06 2009
From: christian at automatick.net (christian)
Date: Tue, 29 Sep 2009 20:34:06 -0700
Subject: [c-nsp] Hardware for 'managed firewall'
In-Reply-To: <Pine.LNX.4.63.0909292220430.28960@charmed.internetsolver.com>
References: <4AC271C6.1090508@reachone.com>
	<Pine.LNX.4.63.0909291604180.17496@charmed.internetsolver.com>
	<F48AF478-5AAD-495C-AAB2-409C132EA8F2@hughes.com.au>
	<Pine.LNX.4.63.0909292220430.28960@charmed.internetsolver.com>
Message-ID: <c4d480f60909292034v5e7eb351i130862e5c887aaf5@mail.gmail.com>

netscreen management (cli/NSM) is one of the worst i've ever encountered

as far as the topic at hand - i agree w/ Justin's comments - what i've
done in past is FWSM's in the chassis and a pair of asa's for vpn
termination

On Tue, Sep 29, 2009 at 8:23 PM, Dave Weis <djweis at internetsolver.com> wrote:
>
> On Wed, 30 Sep 2009, David Hughes wrote:
>>
>> On 30/09/2009, at 7:08 AM, Dave Weis wrote:
>>>
>>> On Tue, 29 Sep 2009, Christopher Hunt wrote:
>>>>
>>>> As I painfully discovered, the Cisco ASA in Multiple Context mode does
>>>> not support IPSEC VPN clients nor L2TP3 tunnels
>>>
>>> That's a pretty big omission! Any ETA to add that capability?
>>
>> Yeah, they've never supported VPN in multi-context mode. ?Major pain. ?And
>> if you are a dense hosting provider the 50 context limit (and limited
>> performance) of a 5540 for example doesn't work too well. ?These issues made
>> us look around again and J-Vendor's boxes are making the ASA's look a bit
>> ordinary.
>
> I never enjoyed working on the netscreens. I suppose if each virtual
> firewall customer could get the same awkward web interface for self
> provisioning it could be made to work.
>
> --
> Dave Weis
> djweis at internetsolver.com
> http://www.internetsolver.com/
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From mumetahh at yahoo.co.id  Wed Sep 30 00:54:54 2009
From: mumetahh at yahoo.co.id (==N==)
Date: Tue, 29 Sep 2009 21:54:54 -0700 (PDT)
Subject: [c-nsp] Syslog Analyzer
Message-ID: <418494.43750.qm@web76301.mail.sg1.yahoo.com>

Dear All,

I have configure my Linux/CentOS as my syslog server which is all my networking devices send their syslog to centralize in one server, and it's already done and working well.

I need some recomendation for syslog analyzer for easier us to monitoring the log? which is graphical web base so I easy to see each devices and organise the device log. I use standard syslogd.

Thank you in advanced for the best recomenddation.

Regards



-Nicky-

" Fly Higher - Run Faster "
http://suryantofang.wordpress.com




      Jatuh cinta itu seperti apa ya rasanya? Temukan jawabannya di Yahoo! Answers! http://id.answers.yahoo.com

From andrea.francesconi at gmail.com  Wed Sep 30 02:24:55 2009
From: andrea.francesconi at gmail.com (fRANz)
Date: Wed, 30 Sep 2009 08:24:55 +0200
Subject: [c-nsp] Syslog Analyzer
In-Reply-To: <418494.43750.qm@web76301.mail.sg1.yahoo.com>
References: <418494.43750.qm@web76301.mail.sg1.yahoo.com>
Message-ID: <25dd2ab90909292324w449a9d0bwadb1dcf188180f0c@mail.gmail.com>

On Wed, Sep 30, 2009 at 6:54 AM, ==N== <mumetahh at yahoo.co.id> wrote:

> Dear All,
>
> I have configure my Linux/CentOS as my syslog server which is all my networking devices send their syslog to centralize in one server, and it's already done and working well.
>
> I need some recomendation for syslog analyzer for easier us to monitoring the log? which is graphical web base so I easy to see each devices and organise the device log. I use standard syslogd.

Did you already seen Splunk?
http://www.splunk.com/

Regards,
-f

From francis.s.mendoza at gmail.com  Wed Sep 30 02:41:59 2009
From: francis.s.mendoza at gmail.com (francis mendoza)
Date: Wed, 30 Sep 2009 14:41:59 +0800
Subject: [c-nsp] Syslog Analyzer
In-Reply-To: <25dd2ab90909292324w449a9d0bwadb1dcf188180f0c@mail.gmail.com>
References: <418494.43750.qm@web76301.mail.sg1.yahoo.com>
	<25dd2ab90909292324w449a9d0bwadb1dcf188180f0c@mail.gmail.com>
Message-ID: <4ac0ee440909292341j22882a0dt433903d3ec13753e@mail.gmail.com>

try http://www.sawmill.net/

On Wed, Sep 30, 2009 at 2:24 PM, fRANz <andrea.francesconi at gmail.com> wrote:

> On Wed, Sep 30, 2009 at 6:54 AM, ==N== <mumetahh at yahoo.co.id> wrote:
>
> > Dear All,
> >
> > I have configure my Linux/CentOS as my syslog server which is all my
> networking devices send their syslog to centralize in one server, and it's
> already done and working well.
> >
> > I need some recomendation for syslog analyzer for easier us to monitoring
> the log  which is graphical web base so I easy to see each devices and
> organise the device log. I use standard syslogd.
>
> Did you already seen Splunk?
> http://www.splunk.com/
>
> Regards,
> -f
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



-- 
thanks
./francis

From eng_mssk at hotmail.com  Wed Sep 30 02:50:42 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Wed, 30 Sep 2009 09:50:42 +0300
Subject: [c-nsp] Power and Voltage Values
Message-ID: <BLU102-W10F9A9E32682C1F18F10FAFAD40@phx.gbl>


hey all 

i have 2 devices 
cisco ME-C6524GT-8S (R7000) processor with IOS sup-bootflash:s6523-advipservicesk9-mz.122-18.ZU2.bin
ME-C3750-24TE with IOS flash:c3750me-i5-mz.122-35.SE5/c3750me-i5-mz.122-35.SE5.bin

when issue the below commands 
router#sh environment 
environmental alarms:
  no alarms
fan-tray 1: 
  fan-tray 1 type: FAN-C6524
  fan-tray 1 fan-fail: OK
power-supply 1: 
  power-supply 1 fan-fail: OK
  power-supply 1 power-input: DC
  power-supply 1 power-output-fail: OK
module 1: 
  module 1 power-output-fail: OK
  module 1 outlet temperature: 28C
  module 1 inlet temperature: 24C
  module 1 asic-1 (HYPERION-3) temp: 41C
  module 1 asic-2 (DHANUSH-3) temp: 34C
  module 1 asic-3 (DHANUSH-3) temp: 34C
  module 1 RP outlet temperature: 22C
  module 1 RP inlet temperature: 18C
  module 1 EARL outlet temperature: 28C
  module 1 EARL inlet temperature: 19C

there are values for voltage , power or ampere
and on the ME swithches , there are no values either

how can i obtain values (numbers) for power ?

and temperature values for ME ??

thanks





 		 	   		  
_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

From vitya at list.ru  Wed Sep 30 02:40:43 2009
From: vitya at list.ru (victor)
Date: Wed, 30 Sep 2009 10:40:43 +0400
Subject: [c-nsp] send multicast over non-multicast-enabled switch
In-Reply-To: <FDD1CDB3FB499E4087CC7670BBCA22C6581B69@XMB-AMS-101.cisco.com>
References: <op.u0y7o82a2vrlim@localhost.localdomain>
	<FDD1CDB3FB499E4087CC7670BBCA22C6581B69@XMB-AMS-101.cisco.com>
Message-ID: <op.u014t5cw2vrlim@localhost.localdomain>

Thank you Arie
It indeed works through GRE though linux box doesn't want to respond to  
IGMP query. But I hope I'll fix it.
As for getting a new connectivity module the question is all about money  
or lack of it.

On Mon, 28 Sep 2009 23:52:21 +0400, Arie Vayner (avayner)  
<avayner at cisco.com> wrote:

> Victor,
>
> You could actually use GRE for that. The 7600 can do GRE in hardware
> (assuming you have Sup720 and up).
>
> You need to make sure that the multicast source would be an IP routed
> through the GRE tunnel on the 7600, or else you would get RPF failures.
>
> I would say the best practice would be to get a switch that can handle
> multicast, and the above would be a workaround.
>
> Arie
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of victor
> Sent: Monday, September 28, 2009 19:28
> To: cisco-nsp at puck.nether.net
> Cc: cisco-nsp at puck.nether.net
> Subject: [c-nsp] send multicast over non-multicast-enabled switch
>
> Hi.
> I was assigned with a task to set up a video streaming server and use a
>
> blade server for it. The problem is that the network connectivity module
>
> for the blade chassis is not dotQ multicast aware and simply drop all
> the
> 224.0.0.0/4 data. What options do I have to get the traffic through? I
> am
> thinking may be it is possible to encapsulate the stream into gre and
> then
> safely transport it to the RP? Or may be I can send it as unicast and
> then
> convert it somehow into multicast? Is there a best practices guide for
> this matter?
> The blade runs Linux and over the trunk connected to the RP which is
> Cisco
> 7604.
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From gkg at gmx.de  Wed Sep 30 03:39:19 2009
From: gkg at gmx.de (Garry)
Date: Wed, 30 Sep 2009 09:39:19 +0200
Subject: [c-nsp] Syslog Analyzer
In-Reply-To: <418494.43750.qm@web76301.mail.sg1.yahoo.com>
References: <418494.43750.qm@web76301.mail.sg1.yahoo.com>
Message-ID: <4AC30B27.6010700@gmx.de>

OpenNMS has syslog collectors, too, so if you also require some
additional features for network monitoring, that may be the way to go
... also, it's open source ... :)

-garry

From zivl at gilat.net  Wed Sep 30 03:45:59 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Wed, 30 Sep 2009 09:45:59 +0200
Subject: [c-nsp] Syslog Analyzer
In-Reply-To: <418494.43750.qm@web76301.mail.sg1.yahoo.com>
References: <418494.43750.qm@web76301.mail.sg1.yahoo.com>
Message-ID: <EC993E87D960A541A66BF21D62AA42A6232C85C812@exch2k7.gilat.local>

If you are looking for a free, open source software there's php-syslog-ng
http://code.google.com/p/php-syslog-ng/



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of ==N==
Sent: Wednesday, September 30, 2009 6:55 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Syslog Analyzer

Dear All,

I have configure my Linux/CentOS as my syslog server which is all my networking devices send their syslog to centralize in one server, and it's already done and working well.

I need some recomendation for syslog analyzer for easier us to monitoring the log? which is graphical web base so I easy to see each devices and organise the device log. I use standard syslogd.

Thank you in advanced for the best recomenddation.

Regards



-Nicky-

" Fly Higher - Run Faster "
http://suryantofang.wordpress.com




      Jatuh cinta itu seperti apa ya rasanya? Temukan jawabannya di Yahoo! Answers! http://id.answers.yahoo.com
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp