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